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

Scale FW cruise throttle based on baro pressure #8304

Merged
merged 1 commit into from
Nov 24, 2017
Merged

Conversation

sanderux
Copy link
Member

@sanderux sanderux commented Nov 17, 2017

This provides a method to scale cruise throttle based on altitude AMSL.
Mostly useful for flying without airspeed sensor on varying altitudes.

SITL tested and disabled by default.
Would be great if this could still make 1.7

@dagar
Copy link
Member

dagar commented Nov 17, 2017

This seems fine, although shouldn't it be done in the position controller? The position controller depends on position (obviously), deals with altitude, and actively controls throttle. The attitude controller really shouldn't have any dependency on these things.

@sanderux
Copy link
Member Author

I was trying to keep all throttle scaling together. It had global pos anyway for groundspeed

@LorenzMeier
Copy link
Member

@priseborough any feedback?

@dagar
Copy link
Member

dagar commented Nov 17, 2017

Manual mode and stabilized should maintain manual throttle passthrough. For example think about something going wrong with the global position (altitude) estimate.

I actually don't think any throttle scaling should happen at this level, but that's another discussion.

@LorenzMeier
Copy link
Member

I agree with the safety argument. And I think the throttle scaling should definitely come out of TECS, as this is an alternate mode of controlling altitude.

@sanderux
Copy link
Member Author

Ok, i'll move it to pos ctl. I dont think tecs has absolute altitude.

@priseborough
Copy link
Contributor

A complication is that the TECS total energy controller for throttle contains an integrator which needs to know if throttle is saturated.

Additionally TECS relies on throttle_max passed through being the throttle required to climb at FW_T_CLMB_MAX and throttle_min being the throttle required to descend at FW_T_SINK_MIN when flying at the current speed demand.

This means corrections for the change in performance with altitude should be achieved by modifying the throttle_min and throttle_max value passed through to TECS, rather than scaling the TECS throttle output.

@sanderux sanderux changed the title Added param to allow throttle scaling based on altitude ASML Added param to allow throttle scaling based on altitude AMSL Nov 17, 2017
@sanderux
Copy link
Member Author

Moved to pos ctl

@sanderux
Copy link
Member Author

@priseborough For now its only extending an already existing scaler on throttle (voltage).
Your point on min and max values i understand, however, we (and with me i think many people) have these set 'safe' so altitude is accounted for.

@sanderux sanderux changed the title Added param to allow throttle scaling based on altitude AMSL Scale FW cruise throttle based on baro pressure Nov 18, 2017
@priseborough
Copy link
Contributor

Can you at least limit the scale adjustment so that physical throttle won't clip before TECS throttle has reached its own upper limit.

@sanderux sanderux force-pushed the pr-fw_thr_alt_scl branch 2 times, most recently from 573c319 to 52f8fbc Compare November 21, 2017 01:28
if (orb_copy(ORB_ID(sensor_baro), _sensor_baro_sub, &baro) == PX4_OK) {
// scale throttle as a function of sqrt(p0/p) (~ EAS -> TAS at low speeds and altitudes ignoring temperature)
const float scale = constrain(sqrtf(MSL_PRESSURE_MILLIBAR / baro.pressure), 0.9f, 1.1f);
throttle_cruise = throttle_cruise * scale;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

throttle_max should also be scaled up to a max value of 1.0 to prevent possible loss of speed an stalling during climbs at altitude.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you elaborate on 1.0? shouldnt the same scaling apply? or do you mean as a lower limit?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or do you mean an absolute value of 1.0f ?

* @boolean
* @group FW L1 Control
*/
PARAM_DEFINE_INT32(FW_THR_ALT_SC_EN, 0);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thus should be a float that multiplies by the pressure ratio to set the scale correction. A fixed ratio of 1 is not going to work for all propulsion types.

@priseborough
Copy link
Contributor

At the moment It's only adjusting throttle_cruise up and down. It should also adjust throttle_max up to a maximum of 1.0, otherwise there may be insufficient throttle to maintain safe airspeed during climbs without an airspeed sensor.

Also, why make the gain from pressure ratio to throttle either 1.0 or nothing? A unity scaling from pressure ratio to throttle scaler seems arbitrary and will not work for all propulsion types.

@sanderux
Copy link
Member Author

@priseborough i'll address your comments, they make sense.
Should we also scale thr_min?

@bresch
Copy link
Member

bresch commented Nov 21, 2017

@sanderux Good idea, we should also add this for the multicopter part (but in the mixer since the input of the multicopter mixer are forces and moments). It would be nice to scale with the air temperature too (sqrt(T/T_ref)) if a reliable measurement is available.

@priseborough
Copy link
Contributor

I don't think we have a basis for specifying how to scale throttle_min. It would depend on whether you were using the propeller as a brake or a thruster during that flight condition.

Also have you thought about using the eas2tas instead of pressure ratio? With voltage or RPM control of the motor and a fixed pitch prop this does have a physical basis and will compensate for loss of air density and the higher TAS required at higher air temperatures.

@sanderux
Copy link
Member Author

@priseborough this method was mostly meant for flying without airspeed sensor. I will address your scaling issue and apply to throttle_max too

@priseborough
Copy link
Contributor

Sorry, I forgot that eas2tas wasn't available without an airspeed sensor.

@sanderux
Copy link
Member Author

@dagar @priseborough changes made, please do another pass

* When flying without airspeed sensor this will help to keep a constant performance over large altitude ranges.
*
* A value of 0 will disable scaling.
* A value of 1 will add 1% throttle for every 1% of pressure descrease relative to standard pressure (1013.25)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Param description out of date.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Whats out of date about it? i just rewrote it

@dagar dagar force-pushed the pr-fw_thr_alt_scl branch 2 times, most recently from ac632c3 to 2b18cda Compare November 23, 2017 20:32
@dagar
Copy link
Member

dagar commented Nov 23, 2017

I fixed the trivial CI failure (formatting), moved the scaling to within the constrain, and added finite checks for the baro and input parameter. I also increased the scaling maximum incase you want to go flying on everest or something.

I still think the param description could be improved, but I'm fine with merging this.

@priseborough @bresch any suggestions for describing the scaling parameter?

Scale throttle by pressure

This parameter enables throttle scaling based on barometric pressure
When flying without airspeed sensor this will help to keep a constant performance over large altitude ranges.

A value of 0 will disable scaling.
A value of 1 will add 1% throttle for every 1% of pressure descrease relative to standard pressure (1013.25)

It seems to me we should be saying something about propulsion types.

const float scale = constrain(eas2tas * _parameters.throttle_alt_scale, 0.9f, 1.8f);

throttle_cruise = throttle_cruise * scale;
throttle_max = throttle_max * scale;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

limit throttle_max upper value to 1.0 and limit upper value of throttle_cruise to be lower than throttle_max.

@priseborough
Copy link
Contributor

priseborough commented Nov 23, 2017

I'm OK with describing what it does and leaving it to the user to tune. It is an advanced user parameter and set to 0 by default. We can update the description with suggested values when we have some flight test data of performance modelling for different propulsion system setups.

@sanderux
Copy link
Member Author

Looks good to me now

dagar
dagar previously approved these changes Nov 24, 2017
@priseborough
Copy link
Contributor

DO NOT PUSH this PR

@priseborough
Copy link
Contributor

My previous comment has not been addressed. It still allows throttle_cruise = throttle_max which will cause a div0 condition here: https://github.com/PX4/ecl/blob/master/tecs/tecs.cpp#L351

Copy link
Member

@LorenzMeier LorenzMeier left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please address the concerns from @priseborough.

@LorenzMeier
Copy link
Member

@sanderux Please handle this with priority - we are now ready to release otherwise and it would be bad if your users would have a suboptimal experience without this patch.

@sanderux
Copy link
Member Author

I'm on it

@sanderux
Copy link
Member Author

@LorenzMeier @dagar @priseborough
I changed the constrain to always be at least 1% above throttle_min and 1% below throttle_max

@sanderux
Copy link
Member Author

SITL tested, all still works as expected

@sanderux sanderux merged commit b305900 into master Nov 24, 2017
@sanderux sanderux deleted the pr-fw_thr_alt_scl branch November 24, 2017 15:34
@dagar
Copy link
Member

dagar commented Nov 24, 2017

Looks good, but we never check it otherwise (param updates, or DO_CHANGE_SPEED). I'm going to do the constrain in general in another PR>

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

Successfully merging this pull request may close these issues.

5 participants