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

VTOL parameter cleanup #8967

Merged
merged 18 commits into from
Mar 7, 2018
Merged

VTOL parameter cleanup #8967

merged 18 commits into from
Mar 7, 2018

Conversation

RomanBapst
Copy link
Contributor

@RomanBapst RomanBapst commented Feb 26, 2018

  • moved many generic parameters out of standard.cpp into vtol_type class so that not every vtol_type needs to define the same parameter again
  • cleaned up usage of hrt_elapsed_time (thanks @bkueng for suggestions)

Needs CAREFUL review and fair amount of testing!

Next: Do the same thing for tiltrotor.cpp and tailsitter.cpp

SITL testing:

Standard VTOL Transitions

  • Manual
  • Stabilized
  • Altitude
  • Position
  • Mission

Tiltrotor Transitions

  • Manual
  • Stabilized
  • Altitude
  • Position
  • Mission

Tailsitter Transitions

  • Manual
  • Stabilized
  • Altitude
  • Position
  • Mission

@@ -277,39 +233,38 @@ void Standard::update_vtol_state()
void Standard::update_transition_state()
{
float mc_weight = 1.0f;
float time_now = (float)hrt_absolute_time();
Copy link
Member

Choose a reason for hiding this comment

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

Why are you keeping this as a float?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dagar Are you only asking about time_now or also about time_since_trans_start below?
You are right, I don't need to have this as a float, I can cast it to a float in the computation of time_since_trans_start.
Not sure if you were debating about storing values as float vs integers.

Copy link
Member

Choose a reason for hiding this comment

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

I mean keep it as a uint64 if working in microseconds, or convert to seconds and keep it as a float. For everything in this VTOL controller seconds is good enough, and easier to work with (fits with parameters).


/* duration of a forwards transition to fw mode */
param_get(_params_handles_standard.front_trans_dur, &v);
_params_standard.front_trans_dur = math::constrain(v, 0.0f, 20.0f);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dagar What do you think about these things? If we want them we need to add them to the vtol_att_control_main.cpp which handles most params now. The questions is if this makes sense in general?

Copy link
Member

Choose a reason for hiding this comment

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

The intent is good, but I don't like that your actual parameter value isn't used. In many cases these constraint aren't necessary because the param metadata prevents invalid user data. At a minimum I'd want to see the effective parameter value committed.

Copy link
Member

Choose a reason for hiding this comment

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

I agree to remove the constrain as UI will make clear not to go beyond that

// Handle throttle reversal for active breaking
float thrscale = (float)hrt_elapsed_time(&btrans_start) / (_params_standard.front_trans_dur *
1000000.0f);
float thrscale = (time_now - btrans_start) / (_params_standard.pusher_ramp_dt * 1e6f);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sanderux I need your input here. You were using the parameter for the front transition duration for this calculation related to active breaking. I introduced a parameter for the pusher ramp up time so that we don't need to abuse the front transition time param anymore. Can you plz check if I used the correct param?

@RomanBapst
Copy link
Contributor Author

@dagar We decided to move away from computing elapsed time in microseconds and compute elapsed time in seconds instead. It avoids all the conversions as all our parameters are already in seconds. Can you have a look?

@RomanBapst RomanBapst force-pushed the pr-standard-param-cleanup branch from e7a8d50 to f015809 Compare February 28, 2018 08:57
(_params_tiltrotor.airspeed_trans - _params_tiltrotor.airspeed_blend_start);
if (!_params->airspeed_disabled && _airspeed->indicated_airspeed_m_s >= _params->airspeed_blend) {
_mc_roll_weight = 1.0f - (_airspeed->indicated_airspeed_m_s - _params->airspeed_blend) /
(_params->transition_airspeed - _params->airspeed_blend);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Need to put the check somewhere to make sure that transition_airspeed and airspeed_blend are not equal.

Copy link
Member

Choose a reason for hiding this comment

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

Did you do that already?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bkueng Yes, I put in a constraint which holds for all three vtol types.

@@ -277,39 +232,36 @@ void Standard::update_vtol_state()
void Standard::update_transition_state()
{
float mc_weight = 1.0f;
float time_since_trans_start = (float)(hrt_absolute_time() - _vtol_schedule.transition_start) * 1e-6f;
Copy link
Member

Choose a reason for hiding this comment

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

float time_since_trans_start = hrt_elapsed_time(&_vtol_schedule.transition_start) * 1e-6f

} else if (_params->airspeed_disabled &&
time_since_trans_start < _params->front_trans_time_min &&
time_since_trans_start > _params->front_trans_time_min / 2.0f) {
mc_weight = 1.0f - ((time_since_trans_start - _params->front_trans_time_min / 2.0f) /
Copy link
Member

Choose a reason for hiding this comment

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

I believe this simplifies to
float weight = 1.0f - (time_since_trans_start / _params->front_trans_time_min);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@dagar Not really, I think the intent is to start the weight from zero when time_since_trans_start is half of front_trans_time_min.
By the way, I mostly wanted to keep this PR as pure refactoring and not change any functional stuff.

Copy link
Member

Choose a reason for hiding this comment

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

I'm talking about keeping it the same functionally, but in a somewhat comprehensible form.

const float weight = 1.0f - (time_since_trans_start / _params->front_trans_time_min);
_mc_throttle_weight = math::constrain(2.0f * weight, 0.0f, 1.0f);

@dagar
Copy link
Member

dagar commented Feb 28, 2018

@dagar We decided to move away from computing elapsed time in microseconds and compute elapsed time in seconds instead. It avoids all the conversions as all our parameters are already in seconds. Can you have a look?

Yes that's fine, the problem I saw earlier was using microseconds in a float.

@RomanBapst RomanBapst force-pushed the pr-standard-param-cleanup branch 2 times, most recently from 15940a3 to 21e6e35 Compare March 1, 2018 08:19
@RomanBapst RomanBapst changed the title [WIP] Pr standard param cleanup VTOL parameter cleanup Mar 1, 2018
@RomanBapst
Copy link
Contributor Author

@dagar I'd like to get this in as soon as possible. Do you think we should ask the flight test team to give it a try?

@RomanBapst
Copy link
Contributor Author

@dagar I verified that #8988 is not related to this because it also is happening on master. So I'm pretty confident about this.

@dagar
Copy link
Member

dagar commented Mar 1, 2018

It all looks reasonable and likely works with the defaults. The only concern is that we miss some trivial param thing because there's almost no error handling. That's one of the reasons I wanted to go to BlockParam.

Copy link
Member

@bkueng bkueng left a comment

Choose a reason for hiding this comment

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

Nice, this is much more readable!

_mc_pitch_weight = 1.0f * (float)hrt_elapsed_time(&_vtol_schedule.transition_start) /
(_params_tailsitter.back_trans_dur * 1000000.0f);
// smoothly move control weight to MC
_mc_roll_weight = _mc_pitch_weight = 1.0f * time_since_trans_start / _params->back_trans_duration;
Copy link
Member

Choose a reason for hiding this comment

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

1.0f * can be dropped

(_params_tiltrotor.airspeed_trans - _params_tiltrotor.airspeed_blend_start);
if (!_params->airspeed_disabled && _airspeed->indicated_airspeed_m_s >= _params->airspeed_blend) {
_mc_roll_weight = 1.0f - (_airspeed->indicated_airspeed_m_s - _params->airspeed_blend) /
(_params->transition_airspeed - _params->airspeed_blend);
Copy link
Member

Choose a reason for hiding this comment

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

Did you do that already?

@@ -57,7 +57,7 @@ param set SYS_AUTOSTART 13006
param set SYS_MC_EST_GROUP 2
param set SYS_RESTART_TYPE 2
param set VT_MOT_COUNT 4
param set VT_TRANS_THR 0.75
param set VT_F_TRANS_THR 0.75
Copy link
Member

Choose a reason for hiding this comment

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

Do we need some logic to automatically update existing values from VT_TRANS_THR to VT_F_TRANS_THR for people who have set VT_TRANS_THR?

Copy link
Member

Choose a reason for hiding this comment

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

This change can cause crashes on airspeedsensorless vtols
Can we default to 100% ?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@sanderux I defaulted the param to 100%

((_params_standard.front_trans_time_min / 2.0f) * 1000000.0f));
} else if (_params->airspeed_disabled) {
mc_weight = 1.0f - (time_since_trans_start - _params->front_trans_time_min) / _params->front_trans_time_min;
mc_weight = math::constrain(2.0f * mc_weight, 0.0f, 1.0f);
Copy link
Member

Choose a reason for hiding this comment

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

If I see this correct, this changes the logic:

m := _params_standard.front_trans_time_min
t : = time_since_trans_start
previous:
if t < m && t > m/2:
  w = 1 - (t - m/2)/(m/2) = 1 - t/m*2 + 1 = 2 - 2 * t/m
new:
 w = 1 - (t-m)/m = 1 - t/m + 1 = 2 - t/m
 w = constrain(2 * w, 0, 1)        -->  4 - 2*t/m

Is that the intention?

Copy link
Member

Choose a reason for hiding this comment

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


/* duration of a forwards transition to fw mode */
param_get(_params_handles_standard.front_trans_dur, &v);
_params_standard.front_trans_dur = math::constrain(v, 0.0f, 20.0f);
Copy link
Member

Choose a reason for hiding this comment

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

I agree to remove the constrain as UI will make clear not to go beyond that

sanderux
sanderux previously approved these changes Mar 1, 2018
@sanderux sanderux dismissed their stale review March 1, 2018 18:40

Trying to correct my review

@RomanBapst RomanBapst force-pushed the pr-standard-param-cleanup branch from 21e6e35 to 390b2fc Compare March 2, 2018 14:15
@RomanBapst
Copy link
Contributor Author

@PX4/testflights Could you please test this on a standard VTOL?

@r0gelion
Copy link
Contributor

r0gelion commented Mar 5, 2018

@RomanBapst we're going to the flying field tomorrow and we will test this PR.

@santiago3dr
Copy link

flight on standard delta-quad running pixhawk 1 (v2):
https://logs.px4.io/plot_app?log=d3b71a4f-aa03-44fe-8afb-a6d65ec13240

compared to current master:
https://logs.px4.io/plot_app?log=a0fe8530-da7f-4f21-ae4c-4fdeaa9b5658

good flight performance; nothing out of the ordinary

…_elapsed time

- standard vtol was implementing many custom parameters although they
are generic and should be shared between the vtol types
- removed heavy usage of hrt_elapsed_time() which is a system call and
could be computationally expensive
…sing

microseconds

- seconds is more intuitive
- avoids tons of divisions by 1e6f

Signed-off-by: Roman <[email protected]>
- do not call hrt_elapsed_time since it's expensive
- remove P2 front transition phase (was not even used)

Signed-off-by: Roman <[email protected]>
- more intuitive
- avoids tons of divisions

Signed-off-by: Roman <[email protected]>
- more intuitive
- avoids tons of divisions

Signed-off-by: Roman <[email protected]>
@RomanBapst RomanBapst force-pushed the pr-standard-param-cleanup branch from 6962fa5 to 0aa0869 Compare March 7, 2018 10:23
- the main idea is to prevent airspeed less systems to stall after a
transition

Signed-off-by: Roman <[email protected]>
@RomanBapst RomanBapst merged commit ac2b3cc into master Mar 7, 2018
@RomanBapst RomanBapst deleted the pr-standard-param-cleanup branch March 7, 2018 13:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants