Servers by jDrones

Throttle drop when switching to Loiter from RTL


(Sergey) #24

Forgot to clarify the RTL to loiter case is on the 14 minute
@rmackay9


(Sergey) #25

I’m looking at recent log and got confused more and more. There is still the Alt-DAlt divergence.
I’m think I don’t understand what a DAlt means at LAND mode at all. DCrt indeed makes sense but not DAlt.
Does the land controller actually controls the DAlt value not the DCrt?


(rmackay9) #26

@sergbokh

I think in LAND mode the desired altitude is still updated. Copter integrates the desired climb rate into the desired altitude.


(Sergey) #27

Hi Randy,
thanks, I’m stuck with that. Have no idea what should I try further to get to the bottom of that issue.

BTW, any idea why LAND uses WP_SPEED_DN instead of LAND_SPEED?


(rmackay9) #28

@sergbokh,

In LAND mode, I think the vehicle will descend at either the LAND_SPEED or the LAND_SPEED_HIGH parameter value.

From looking at the 40.BIN log posted above, it doesn’t look like the vehicle is ever in LAND mode so perhaps you mean the last stage of RTL mode? In RTL mode it should descend quickly until it reaches about 10m and then it slows down to the LAND_SPEED.


(Sergey) #29

That’s correct. I didn’t know the final stage consists of descending and landing with its own rates.

So my test was not correct. I will retest in LAND mode and see if the issue with throttle occurs.


(Sergey) #30

Did another 3 tests this weekend.
WP_SPEED_DN is 350 and LAND_SPEED is 200.

  • Descending in LAND then switch to Loiter: everything is OK.
  • Descending as RTL step then switch to Loiter (TEST1 on screenshot): drop in climb rate. Still nothing changed here.
  • Hovering as RTL step after descend then switch to Loiter (TEST2): drop in climb rate again

The drop is in TEST2 is something new I didn’t aware of. May be it could be a hint for someone who knows how attitude control works in arducopter.


(Sergey) #31

From logs; DCrt is negative right after Loiter engaged.
2018-11-11 14:37:16.514 | DCrt = -1
2018-11-11 14:37:16.583 | MODE Loiter
2018-11-11 14:37:16.617 | Dcrt = -289


(Sergey) #32

Just an assumption, not digging into the code very deep.
I’m using a RTL_ALT_FINAL = 1000 so as per source codes there shall be no LAND at the end of RTL at all (by design).
OK, so after the copter reaches the 1000cm it just stuck in Copter::ModeRTL::descent_run() forever.

Note this method uses following lines:
// call z-axis position controller
pos_control->set_alt_target_with_slew(rtl_path.descent_target.alt, G_Dt);
pos_control->update_z_controller();

Then, if you switch to a Loiter, there is the Init():
// initialise position and desired velocity
if (!pos_control->is_active_z()) {
pos_control->set_alt_target_to_current_alt();
pos_control->set_desired_velocity_z(inertial_nav.get_velocity_z());
}
I think is_active_z() == true so this actions are not executed.


(Sergey) #33

@rmackay9
good news, this is reproducible with SITL autotest


(rmackay9) #34

@sergbokh,

Oh really? I haven’t been able to reproduce it in SITL in the past but I guess it’s the RTL_ALT parameter that is key? So once that is set it is reproduce-able? I’ll give it a try…


(Sergey) #35

I’ve added test details to the ticket https://github.com/ArduPilot/ardupilot/issues/7435
Yes, seems RTL_ALT_FINAL is the key to repro.


(Sergey) #36

@rmackay9
I see this your commit added the condition.

Previously we always reset the altitude target to the current altitude but this causes a jump if the vehicle is already in an alt-hold flight mode but has an altitude error

Could you please clarify “an altitude error” means the altitude estimation error or means that current Alt != Desired Alt?

And if it’s all about the altitude then doesn’t the code look like:

if (!pos_control.is_active_z()) {
    pos_control.set_alt_target_to_current_alt();
    }

pos_control.set_desired_velocity_z(inertial_nav.get_velocity_z());

(rmackay9) #37

@sergbokh,

yes, when referring to “altitude error” I meant that there was a difference between the desired and actual altitude.

It’s super clear what the issue is now I think. The initialisation of the altitude target in the descent_start() method is not quite right. This line

pos_control->set_target_to_stopping_point_z();

should be changed to this:

if (!pos_control->is_active_z()) {
pos_control->set_alt_target_to_current_alt();
pos_control->set_desired_velocity_z(inertial_nav.get_velocity_z());
}

This is great. Thanks so much for this Sergey. I’ll do a PR later today probably (or you can if you’d like) and we can very likely get this out into Copter 3.6.3.


(Sergey) #38

Thanks Randy,
Sorry, I cannot say the reason and the fix is very clear for me :slight_smile:
PosControl interface is not very intuitive. There are a number of different set_… methods, all with its different side effects. There are also loiter_nav and wp_naw does add confusion, because hierarchy and responsibility of each is not obvious.

Why changing Alt initialization in descend_start() does fix if the alt target then changes continuously in descend_run().

Please make a PR, I will test that.
Thank you!


(Sergey) #39

@rmackay9
Did a fix you proposed, but that didn’t helped. Still a DCrt drop running the same my test.
I didn’t commited, just for a case, my change is


(rmackay9) #40

Sergey,

Well, although I thought it was “perfectly clear” it wasn’t actually. Here’s a fix that I think works. Want to give it a try?


(Sergey) #41

Hi @rmackay9, this does fix one case but not the another one, unfortunately.

Let me re-summarize the issue. Two final RTL steps are affected: a) descending to RTL_ALT_FINAL, b) hovering at RTL_ALT_FINAL.
If you switch to Loiter during step A - you will observe a DCrt drop.
If you switch to Loiter during step B - you will also observe a DCrt drop.

I tested in SITL your latest fix and it does fix the B case only.

The A case is still here:


(rmackay9) #42

Sergey,

Yup, OK. While implementing I thought this might happen. Let me have another look.


(Sergey) #43

Hi @rmackay9

Now after some comprehension I believe the causes of case A and B are not much related.
Case B is a bug, and your fix above does fix it. So it is a must.

Case A is not a bug it is just how attitude control implemented. When switching from RTL to Loiter the DAlt are not changes, but the allowed descend rate is much more in Loiter. So pos_controller immediately applies that new descend rate.

I see two options of how this behavior could be changed:

  • to always set desired altitude with current altitude on Loiter init(). I.e. revert this fix. But this will cause a jumps (because of vehicle inertia). So it isn’t a correct option.
  • to limit the acceleration to smooth the transition. And this is what @peterbarker talked about I think.