Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

EXF722DUAL: RPM filter does not work when gyro_to_use = BOTH #7886

Open
dogjutsu opened this issue Mar 28, 2019 · 13 comments

Comments

Projects
None yet
10 participants
@dogjutsu
Copy link

commented Mar 28, 2019

Describe the bug
When iFlight SucceX F7 TwinG (target: EXF722DUAL) is using both gyros (gyro_to_use = BOTH, which is the default), the rpm filter fails to filter gyro noise. RPM center frequencies appear to be properly tracking RAW noise, but little if any filtering actually occurs. If gyro_to_use is set to FIRST (ie, only one gyro is used), RPM filtering functions as expected.

Plasmatree from flight (diff below) with debug mode DUAL_GYRO and gyro_to_use set to BOTH:
20190327--debug=DUAL_GYRO--gyro_to_us=BOTH
BBL from this flight:
20190327-6--bronco--debug_DUAL_GYRO.zip

Plasmatree from same FC config except debug mode set to GYRO_SCALED and gyro_to_use set to FIRST:
20190327-6--bronco--gyro_to_use_FIRST-debug_GYRO_SCALED
BBL from this flight:
20190327-6--bronco--gyro_to_use_FIRST-debug_GYRO_SCALED.zip

To Reproduce
From firmware defaults, apply EXF722DUAL RPM filter snippet and debug_mode = GYRO_SCALED and blackbox log a flight. Observe in the log (or Plasmatree graphs) that gyro noise from on RPY axis are essentially unaffected by the dynamic notch filter.

Expected behavior
RPY gyro signal is filtered by RPM dynamic notch filter.

Flight controller configuration

# Betaflight / EXF722DUAL (EX7P) 4.0.0 Mar 24 2019 / 19:02:48 (9f67a584b) MSP API: 1.41

# start the command batch
batch start

board_name EXF722DUAL
manufacturer_id 

# name
name MyQuad

# timer
timer A00 0
timer A01 1

# dma
dma pin C06 1
# pin C06: DMA2 Stream 2 Channel 7

# mixer

# servo

# servo mix


# feature
feature -RSSI_ADC
feature -LED_STRIP
feature -TRANSPONDER

# beeper
beeper -GYRO_CALIBRATED
beeper -RX_LOST
beeper -RX_LOST_LANDING
beeper -DISARMING
beeper -ARMING
beeper -ARMING_GPS_FIX
beeper -BAT_CRIT_LOW
beeper -BAT_LOW
beeper -GPS_STATUS
beeper -ACC_CALIBRATION
beeper -ACC_CALIBRATION_FAIL
beeper -READY_BEEP
beeper -DISARM_REPEAT
beeper -ARMED
beeper -SYSTEM_INIT
beeper -ON_USB
beeper -BLACKBOX_ERASE
beeper -CRASH_FLIP
beeper -CAM_CONNECTION_OPEN
beeper -CAM_CONNECTION_CLOSE
beeper -RC_SMOOTHING_INIT_FAIL

# beacon
beacon RX_SET

# map

# serial
serial 0 64 115200 57600 0 115200
serial 1 2048 115200 57600 0 115200

# led

# color

# mode_color

# aux
aux 0 0 0 1800 2100 0 0
aux 1 13 3 1800 2100 0 0
aux 2 26 1 1800 2100 0 0
aux 3 31 3 1800 2100 0 0
aux 4 35 3 1800 2100 0 0

# adjrange

# rxrange

# vtx

# rxfail

# display_name

# master
set gyro_sync_denom = 2
set gyro_lowpass_type = PT1
set gyro_lowpass_hz = 0
set gyro_lowpass2_hz = 150
set dyn_notch_range = MEDIUM
set dyn_notch_width_percent = 0
set dyn_notch_q = 200
set dyn_lpf_gyro_min_hz = 0
set dyn_lpf_gyro_max_hz = 0
set baro_hardware = NONE
set rssi_channel = 7
set rc_smoothing_derivative_hz = 150
set rc_smoothing_input_type = PT1
set rc_smoothing_derivative_type = PT1
set serialrx_provider = CRSF
set blackbox_p_ratio = 64
set dshot_burst = OFF
set dshot_bidir = ON
set motor_pwm_protocol = DSHOT600
set motor_poles = 12
set align_board_pitch = 180
set bat_capacity = 850
set yaw_motors_reversed = ON
set pid_process_denom = 1
set transient_throttle_limit = 10
set osd_warn_core_temp = OFF
set osd_warn_rc_smoothing = OFF
set osd_warn_fail_safe = OFF
set osd_warn_launch_control = OFF
set osd_warn_no_gps_rescue = OFF
set osd_warn_gps_rescue_disabled = OFF
set osd_rssi_alarm = 50
set osd_rssi_pos = 2049
set osd_tim_1_pos = 2551
set osd_tim_2_pos = 2519
set osd_g_force_pos = 2466
set osd_throttle_pos = 2497
set osd_vtx_channel_pos = 2072
set osd_craft_name_pos = 2536
set osd_debug_pos = 2081
set osd_avg_cell_voltage_pos = 2529
set osd_stick_overlay_left_pos = 2305
set osd_stick_overlay_right_pos = 2326
set osd_stat_tim_1 = ON
set osd_stat_max_spd = OFF
set osd_stat_endbatt = ON
set osd_stat_battery = ON
set osd_stat_max_curr = OFF
set osd_stat_used_mah = OFF
set osd_stat_max_g_force = ON
set osd_stat_min_link_quality = ON
set osd_stat_max_fft = ON
set debug_mode = GYRO_SCALED
set scheduler_optimize_rate = ON
set vtx_band = 1
set vtx_channel = 2
set vtx_freq = 5845

# profile
profile 0

set dterm_lowpass_hz = 0
set dterm_lowpass2_type = PT1
set dterm_lowpass2_hz = 0
set iterm_relax_cutoff = 35
set i_pitch = 85
set d_pitch = 28
set i_roll = 80
set d_roll = 30
set p_yaw = 30
set i_yaw = 90
set f_yaw = 30
set abs_control_gain = 0
set d_min_roll = 16
set d_min_pitch = 18
set d_min_advance = 0

# rateprofile
rateprofile 0

set thr_mid = 35
set thr_expo = 75
set roll_rc_rate = 132
set pitch_rc_rate = 132
set yaw_rc_rate = 132
set roll_srate = 55
set pitch_srate = 55
set yaw_srate = 55
set tpa_rate = 75
set tpa_breakpoint = 1400

# end the command batch
batch end

# 

Setup / Versions

  • Flight controller: SucceX F7 TwinG purchased directly from iFlight, behavior observed on Betaflight 4.0 RC2, RC3, and joelucid 'jshot' RC3.
  • ESC: SPEDIX GS25A 4-in-1 with the beta 32.6.8 firmware that supports bidir dshot.

Additional context
uavtech. ghvlaw, and Quad Flyer X worked with me over several days of tests flights and log analysis to narrow down the cause of the unfiltered gyro noise. uavtech has been looking over my logs and can offer more detailed observations if needed.

@etracer65

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

Yes, the way it's currently designed RPM-based filtering will not work with dual-gyro boards running in "BOTH" mode. There are no quick fixes and will require major refactoring. It's also possible it may not be viable as it would require applying and additional full set of gyro notch filters.

@spatzengr

This comment has been minimized.

Copy link

commented Mar 28, 2019

@hydra , this will impact SPracingF7 too.

@etracer65 , I thought it might just be as simple as adding the RPM filtering to the dual gyro filtering stream. From what I gather, each gyro in Dual mode goes through special code where the filtering is applied and then the signal is averaged to fee to the PID loop. Was hoping it would be as simple as bringing the RPM filter call into the pipeline.

@etracer65

This comment has been minimized.

Copy link
Member

commented Mar 28, 2019

At a high level yes, that's what needs to happen. But it's going to require a fair amount of refactoring because the rpm filter gyro notches are currently global - not gyro sensor specific. The other concern is that when this is done it's going to add another 36 notches to the filtering CPU load.

@Schlumie

This comment has been minimized.

Copy link

commented Apr 9, 2019

Wouldnt it be possible to do a simpler fusion/avg with no/less filter and feed that into the normal path where a single gyro normal feeds? Not that effective, but both gyro would be in use/avg. and as you said, the standardway would introduce so many notchfilters which maybe even cant be handle by the CPU.

@darksonny

This comment has been minimized.

Copy link

commented Apr 11, 2019

Can a dev confirm to me please, that if I just use one gyro on that particular board, I'd still be able to access Rpm filter functionality? or is there always some kind of background calculation active on that board?

@etracer65

This comment has been minimized.

Copy link
Member

commented Apr 11, 2019

@darksonny Yes, single gyro will work fine with RPM filtering. In fact if you enable RPM filtering it will automatically switch to single gyro mode.

@SupaflyFPV

This comment has been minimized.

Copy link

commented Apr 18, 2019

if it has to be either / or, I'm curious what gives the most useful filtering results, gyro fusion or RPM filtering...I guess it could be visible with logs of a Succex board testing both...

@Dronek

This comment has been minimized.

Copy link

commented Apr 18, 2019

Does it make sense to apply filters on each gyro stream before fusing them?
I imagine rpm filtering being easier to implement on dual gyro if the "raw" sensor data was fused first and then handled like new "raw" data from a (cleaner) single gyro. Then, all the filtering would be done once, not twice. I guess @Schlumie was stating a similar idea.
Can someone please comment on how much gyro fusion affects latency / delay in addition to filtering?
@spatzengr , @hydra

@hydra

This comment has been minimized.

Copy link
Contributor

commented Apr 19, 2019

Let's put it this way, I'm not worried about CPU usage on the H7EXTREME...

@hydra

This comment has been minimized.

Copy link
Contributor

commented Apr 26, 2019

@joelucid what's the status of Dual Gyro RPM filter, what needs to happen to make progress?

@etracer65

This comment has been minimized.

Copy link
Member

commented Apr 26, 2019

The RPM Filter needs to be changed to either:

  1. Be part of the gyro instance and processed separately for each.
  2. Restructure to filter order to apply the RPM Filter after averaging the samples.

2 is more likely as option 1 adds 36 more filters per loop.

But both are significant and wouldn’t classify as bug fixes and would be deferred to 4.1. Lack of dual gyro support isn’t a bug, just a limitation of the current design.

@nerocide

This comment has been minimized.

Copy link

commented Apr 29, 2019

I'd be very happy to test and give feeback on RPM filter using 2 sensors gyro as soon has it is available in dev.
I'm using SP H7EXTREME.

@mikeller

This comment has been minimized.

Copy link
Member

commented Apr 29, 2019

@nerocide: This won't help us much, as the SPRACINGH7EXTREME is not supported in Betaflight yet. 😞

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.