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

Motor display doesn't indicate motor_output limit or idle values #467

Closed
ctzsnooze opened this issue Aug 17, 2020 · 7 comments · Fixed by #472
Closed

Motor display doesn't indicate motor_output limit or idle values #467

ctzsnooze opened this issue Aug 17, 2020 · 7 comments · Fixed by #472

Comments

@ctzsnooze
Copy link
Member

ctzsnooze commented Aug 17, 2020

I noticed that the motors traces all go to 100% at full throttle, even if motor_output limit is configured to 50% and the motors are actually spinning slower.

I also noticed that the motor trace shows 0% at the DShot idle value. This doesn't provide a visual indicator of the idle value. With dynamic idle, the actual DShot value being sent might transiently go lower than the DShot idle value.

I confirmed that sag compensation and throttle limiting effects do appear in the motor traces as expected.

I wonder if it might be better that we show the motor trace values as percentages of the normal DShot range - ie, to whatever DShot numbers would be if converted to PWM 0-100 by a typical (if there is such a thing) ESC.

Then we can see the actual idle offset and the effect of motor_output_limit more clearly when viewing a log.

@ctzsnooze
Copy link
Member Author

This image shows a log with motor_output_limit at 100% on left and 50% on right.

Note that the motors are shown as being driven to 100% in both cases, even though RPM is lower on right, and battery sage much worse on left, confirming that the output limit is really working..Screen Shot 2020-08-17 at 12 08 52

@ctzsnooze
Copy link
Member Author

ctzsnooze commented Aug 17, 2020

This image shows VBat sag compensation changes being reflected in the motor traces; with successive full throttle bursts, the battery voltage gets lower, and the actual motor drive percent goes higher, as it should.
Screen Shot 2020-08-17 at 11 57 56

@ctzsnooze
Copy link
Member Author

ctzsnooze commented Aug 17, 2020

I note that DShot min and max values are sent to the log header and shown in the 'info' tab of BBE.

It seems that the only way the betaflight user can modify DShot max (other than by customising the code) is with motor_output_limit.

It seems (not sure) that DShot min is 47 + (DShot idle percent * 2000) or something like that, and DShot max is 47 + (motor_output_limit * 20) or something like that. I don't know the details, those are just guesses from the numbers I see.

If so, maybe we could display the motor output percentage as (actual DShot value - 47) /20 ?

The idea is that would still get a 0-100 range.

However, with an absolute range:

  • if DShot idle was 4% and motor_output_limit was 100%,, the motor drive would be shown as 4% when throttle was zero., and 100% at full throttle.
  • if DShot idle was 4% and motor_output_limit was 50%,, the motor drive would be shown as 2% when throttle was zero, and 50% at full throttle.

By my way of thinking this would make it a bit easier to understand a log, particularly now we have dynamic idle and motor_output_limit being actively used.

@McGiverGim
Copy link
Member

I'm not too sure about this. If I'm not wrong, the motors shown at the blackbox are a percentage of the range configured, that I think is what most users want to see, not the "real" value of the motor. To me is indifferent if maximum is 70% or 100%, I only want to know that the motor is at maximum or minimum, the number that goes with it is indifferent, but usually what a user expects is the range from 0% to 100%. But if I'm wrong I don't have any problem to change it.

We can change the value or create an additional field with the commanded raw value sent to the motors or at least with the scale applied for that.

But if you want to play, the value shown in the blackbox is taken from this function:

FlightLog.prototype.rcMotorRawToPct = function(value) {
// Motor displayed as percentage
return Math.min(Math.max(((value - this.getSysConfig().motorOutput[0]) / (this.getSysConfig().motorOutput[1] - this.getSysConfig().motorOutput[0])) * 100.0, 0.0),100.0);
};

Play a little with it, to see if you can get to something that you like. Maybe simply return the value that this function receives. I can help you if you have doubts of how to change it. If I'm not wrong, the this.getSysConfig().motorOutput[0] and this.getSysConfig().motorOutput[1] are the minimum and maximum configured for the motor, and value is the raw motor value that the FC is writing in the Blackbox.

We will need to change the default scale used too for this, if we use the raw value, but for the rest is all here.

@ctzsnooze
Copy link
Member Author

I think this question depends on what the 'purpose' of the motors display is - what we use the logging for, or

betaflight/betaflight#10012 is an example where the user wants to confirm whether or not motor_output_limit is active during turtle mode. If the motor traces in BBE showed the actual effective DShot commands being sent, his question would be easily answered.

If a person has configured motor_output_limit to less than 100, it's good to confirm that it actually is constraining the drive values being sent to the motors, and that it does not change the idle values being sent.

If the user has configured dynamic idle, it is good to see that under strong inflow conditions, the drive to the motors actually goes below the configured DShot idle value.

Personally I would like the motors values to be like the bar graphs in the motors tab - go from 1000 - 2000, in absolute DShot units, when DShot is used.

That makes most sense to me.

I want the 'motors traces' to show what the motors are being told to do, the actual final drive values that they are being sent, after any and all adjustments.

If the 'motors' trace is actually the 'mixer output' trace, and is not the actual 'motor values' trace, then it should be re-named 'mixer output', and we should have a different 'motors' trace that, for DShot, shows 0-2000, the actual drive value to the motor, for example.

Of course, we all know that these values do not show the 'output' or rpm or thrust from the motors; that's not what it means regardless of whether it shows 'mixer output' or 'motor drive signal'.

@ctzsnooze
Copy link
Member Author

ctzsnooze commented Aug 24, 2020

The value of seeing the actual drive values to the motors, scaled from DSHOT_MIN_THROTTLE to DSHOT_MAX_THROTTLE, when the motor protocol is DShot, is of benefit in these situations:

  • when the user enables dynamic idle, they will see motor drive dropping to zero (below the DShot idle value), and be able to see exactly what happens when the Dshot idle value is configured too high
  • while the FC is not armed, the motor drive will be at zero, and on arming, we will see it go up to the DShot idle percent (or whatever idle is active)
  • the log will clearly indicate the magnitude of the idle value in an intuitive and effective way.
  • the log will visually display the effect of setting motor_output_limit
  • it will also clearly show the interaction of motor_output_limit and throttle limit
  • it will clearly show the interaction of motor_output_limit and sag compensation
  • it will facilitate debugging unusual issues related to motor control, or while testing code.

To my way of thinking, these are good improvements in the usefulness of the motor traces, compared to the current approach.

@stale
Copy link

stale bot commented Oct 4, 2020

This issue / pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within a week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants