betaflight / betaflight

Open Source Flight Controller Firmware
GNU General Public License v3.0
8.58k stars 3.03k forks source link

Throttle Scale interferes with Virtual Current #9137

Closed JustAskDave closed 4 years ago

JustAskDave commented 5 years ago

Describe the bug The virtual Current Sensor uses the throttle position to calculate the approximate current draw. This does not seem to take into account if the throttle is scaled in the PID Rate Profile.

I am using little 3in drones in Schools to teach build/program/fly and I have the throttle setup on a 3pos switch via "Adjustments" for the Rate Profile Selection. I have the throttle down to 45% on Pos1, 55% for Pos 2 and unrestricted on Pos 3. This is to give the brand new students stick time with very little sensitivity at first. The Xrotor Nano doesn't have a current sensor so I set up the Virtual Current Sensor which worked great until I introduced the throttle scaling.

To Reproduce Steps to reproduce the behavior: Setting the scale for the virtual current sensor to get an accurate reading with throttle scale at 100% works great. Change PID Rate Profile Throttle Limit to Scale 50% to reduce max available power, the current meter is still reading the actual throttle position and not he scaled throttle position. This causes the virtual current sensor to read much higher than it should.

Expected behavior A clear and concise description of what you expected to happen. Throttle position for the Virtual Current sensor needs to refer to the throttle position applied to the motors using the scaled throttle output and not throttle stick position.

Flight controller configuration Create a diff and post it here in a code block. Put `` (three backticks) at the start and end of thediff` block (instructions on how to do a diff: https://oscarliang.com/use-diff-not-dump-betaflight/)


# version
# Betaflight / STM32F405 (S405) 4.1.0 Oct 16 2019 / 11:57:16 (c37a7c91a) MSP API: 1.42
# manufacturer_id: AIRB   board_name: OMNIBUSF4SD   custom defaults: YES

# start the command batch
batch start

# reset configuration to default settings
defaults nosave

board_name OMNIBUSF4SD
manufacturer_id AIRB
mcu_id 0032001e3436511439373635
signature 

# beacon
beacon RX_LOST
beacon RX_SET

# serial
serial 0 64 115200 57600 0 115200
serial 5 0 115200 57600 0 115200

# aux
aux 0 0 3 1700 2100 0 0
aux 1 1 0 900 1575 0 0
aux 2 2 0 1700 2100 0 0
aux 3 13 1 1300 2100 0 0

# adjrange
adjrange 0 0 2 900 2100 12 2 0 0

# master
set acc_trim_pitch = 6
set acc_calibration = 27,44,71
set serialrx_provider = IBUS
set motor_pwm_protocol = DSHOT600
set motor_poles = 12
set current_meter = VIRTUAL
set ibatv_scale = 130
set ibatv_offset = 23
set small_angle = 45
set pid_process_denom = 1
set osd_vbat_pos = 2497
set osd_current_pos = 2464
set osd_mah_drawn_pos = 2434
set osd_rate_profile_name_pos = 2098
set osd_pid_profile_name_pos = 2086
set gyro_1_align_yaw = 2700

profile 0

# profile 0
set level_limit = 15

profile 1

# profile 1
set level_limit = 30

profile 2

# restore original profile selection
profile 2

rateprofile 0

# rateprofile 0
set roll_rc_rate = 30
set pitch_rc_rate = 30
set yaw_rc_rate = 30
set roll_expo = 75
set pitch_expo = 75
set yaw_expo = 75
set throttle_limit_type = SCALE
set throttle_limit_percent = 45

rateprofile 1

# rateprofile 1
set roll_rc_rate = 50
set pitch_rc_rate = 50
set yaw_rc_rate = 50
set roll_expo = 50
set pitch_expo = 50
set yaw_expo = 50
set throttle_limit_type = SCALE
set throttle_limit_percent = 55

rateprofile 2

# rateprofile 2
set roll_expo = 50
set pitch_expo = 50
set yaw_expo = 50

rateprofile 3

rateprofile 4

rateprofile 5

# restore original rateprofile selection
rateprofile 2

# save configuration

Use resource show all to create a resource allocation list and post it here in a code block. Put ``` (three backticks) at the start and end of the output block.

# resource show all
Currently active IO resource assignments:
(reboot to update)
--------------------
A00: FREE
A01: FREE
A02: MOTOR 4
A03: MOTOR 3
A04: GYRO_CS 1
A05: SPI_SCK 1
A06: SPI_MISO 1
A07: SPI_MOSI 1
A08: FREE
A09: FREE
A10: SERIAL_RX 1
A11: USB
A12: USB
A13: FREE
A14: FREE
A15: OSD_CS
B00: MOTOR 1
B01: MOTOR 2
B02: FREE
B03: PREINIT
B04: BEEPER
B05: LED 1
B06: FREE
B07: SDCARD_DETECT
B08: FREE
B09: FREE
B10: FREE
B11: FREE
B12: SDCARD_CS
B13: SPI_SCK 2
B14: SPI_MISO 2
B15: SPI_MOSI 2
C00: FREE
C01: FREE
C02: ADC_BATT
C03: FREE
C04: GYRO_EXTI
C05: FREE
C06: FREE
C07: FREE
C08: INVERTER 6
C09: INVERTER 3
C10: SPI_SCK 3
C11: SPI_MISO 3
C12: SPI_MOSI 3
C13: FREE
C14: FREE
C15: FREE
D00: FREE
D01: FREE
D02: FREE
D03: FREE
D04: FREE
D05: FREE
D06: FREE
D07: FREE
D08: FREE
D09: FREE
D10: FREE
D11: FREE
D12: FREE
D13: FREE
D14: FREE
D15: FREE
E00: FREE
E01: FREE
E02: FREE
E03: FREE
E04: FREE
E05: FREE
E06: FREE
E07: FREE
E08: FREE
E09: FREE
E10: FREE
E11: FREE
E12: FREE
E13: FREE
E14: FREE
E15: FREE
F00: FREE
F01: FREE
F02: FREE
F03: FREE
F04: FREE
F05: FREE
F06: FREE
F07: FREE
F08: FREE
F09: FREE
F10: FREE
F11: FREE
F12: FREE
F13: FREE
F14: FREE
F15: FREE

Currently active Timers:
-----------------------
TIM1: FREE
TIM2:
    CH3: MOTOR 4
    CH4: MOTOR 3
TIM3:
    CH3: MOTOR 1
    CH4: MOTOR 2
TIM4: FREE
TIM5: FREE
TIM6: FREE
TIM7: FREE
TIM8: FREE
TIM9: FREE
TIM10: FREE
TIM11: FREE
TIM12: FREE
TIM13: FREE
TIM14: FREE

Currently active DMA:
--------------------
DMA1 Stream 0: FREE
DMA1 Stream 1: FREE
DMA1 Stream 2: TIMUP 3
DMA1 Stream 3: FREE
DMA1 Stream 4: FREE
DMA1 Stream 5: FREE
DMA1 Stream 6: FREE
DMA1 Stream 7: TIMUP 2
DMA2 Stream 0: FREE
DMA2 Stream 1: FREE
DMA2 Stream 2: FREE
DMA2 Stream 3: ADC 2
DMA2 Stream 4: FREE
DMA2 Stream 5: FREE
DMA2 Stream 6: FREE
DMA2 Stream 7: FREE

Setup / Versions

Flight Controller is a HobbyWing XRotor Nano F4 (OMNIBUSF4SD) ESC is HobbyWing XRotor Nano 20 amp 4 in 1 Receiver is FlySky FS-A8S micro powered from FC 5v VTX is Turbowing TX1769 powered from VBAT

Additional context Add any other context about the problem here. I that covers it all!

etracer65 commented 5 years ago

Well, I wouldn't exactly call this a bug as it is working the way it's designed and has been this way for quite a while. But it is true that it can be improved. I'll look at changing the calculation to be based on the setpoint throttle which is the final modified value (after applying throttle limit and other modifiers) used in the mixer rather than input throttle percentage. But as an improvement it will be part of 4.2 as changing the behavior in the middle of a release could catch people out as they might experience different results for the virtual current sensor.

JustAskDave commented 5 years ago

Ok cool. I just assumed that no one was using switchable settings of throttle scaling that came in v4.0 and also using virtual current sensors. The virtual current sensor becomes useless if you change the throttle scaling. I had it set with no throttle scaling working great. Set throttle scale to 40% testing and hover went from about 3amps to 12amps and I managed to use almost 2000ma from my 850ma battery! That’s why I presumed it as a bug as I can’t see how anyone could be using the two like that

mikeller commented 5 years ago

@JustAskDave: I think the distinction here (and it's not a hard and fast one) is that you can use the virtual current sensor with throttle scaling, as long as you always use the same throttle scaling, and calibrate the sensor after setting up throttle scaling. This does not work for what you want to do, but there is probably other users out there that use it in this form, and we cannot change this without breaking these users, and probably a bunch of other users of the virtual current sensor, who will have to change the calibration of the sensor after it's been switched to be based off the setpoint throttle. This is something we try to avoid in patch releases - users should be able to update patch releases without having to change their configuration.

JustAskDave commented 5 years ago

Ahh gotcha, yes that makes perfect sense, didn’t think of it that way. Could always add a selection in the virtual current sensor settings to select actual throttle position (default as it does now) or optionally scaled throttle position for fools like me with wierd requests! Wouldn’t affect anyone when it was released that way

mikeller commented 5 years ago

@JustAskDave: Or you could wait for @etracer65's change that solves your issue, and then start using a 4.2 nightly build that solves your problem. :wink:

etracer65 commented 5 years ago

@JustAskDave See #9153

Can you please test? Without throttle limiting, etc. the virtual current meter should perform similarly to now. Although there other factors like throttle boost that will now be (correctly) taken into account when they weren't before. So it's possible with the same calibration you might see slightly higher (but more accurate) current consumption. Although throttle boost effects are generally quicker than the resolution of the current sensor task so there may not be any noticeable difference. When throttle limiting is in effect you should now see it properly reducing the virtual current calculation.

betaflight_4.2.0_OMNIBUSF4SD.hex.zip