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

Pr ground effect zone #11592

Merged
merged 7 commits into from
Mar 21, 2019
Merged

Conversation

EliaTarasov
Copy link
Contributor

@EliaTarasov EliaTarasov commented Mar 5, 2019

Continuation of work on adding ground effect zone.

@RomanBapst
Copy link
Contributor

@EliaTarasov Yes that looks good. What do you think about using the parameter EKF2_GND_EFF_DZ to set the ground effect dead zone and at the same time control enabling / disabling? E.g. if EKF2_GND_EFF_DZ = 0 -> disabled, otherwise enabled.

@EliaTarasov
Copy link
Contributor Author

Yes it's done.

@RomanBapst
Copy link
Contributor

@EliaTarasov Awesome. I will test this on our side, feel free to report your test results.

@EliaTarasov
Copy link
Contributor Author

EliaTarasov commented Mar 5, 2019

  1. Deadzone is disabled
    disabled

  2. Deadzone is 3.0 enabled
    enabled

@RomanBapst
Copy link
Contributor

@EliaTarasov Is that a real flight? From the plots it looks like it worked fine, did it not?

@RomanBapst
Copy link
Contributor

@EliaTarasov Ah, actually I realized there is one thing I wanted to change in the EKF. Currently it will only do the compensation if the vehicle is within 1 m from local_pos.z = 0. This is not very useful in practice as you might not land at the same elevation as you took off and also baro altitude drifts over time.

@EliaTarasov
Copy link
Contributor Author

EliaTarasov commented Mar 5, 2019

@RomanBapst

Is that a real flight? From the plots it looks like it worked fine, did it not?

That's the SITL. I tried to trigger the descent speed to see if the ground effect is also triggred.

Currently it will only do the compensation if the vehicle is within 1 m from local_pos.z = 0. This is not very useful in practice as you might not land at the same elevation as you took off and also baro altitude drifts over time.

Could you then point out what's need to be done to improve it?

@RomanBapst
Copy link
Contributor

@EliaTarasov I can push the fix tomorrow.

@EliaTarasov
Copy link
Contributor Author

@RomanBapst Great, thanks!

@RomanBapst
Copy link
Contributor

@EliaTarasov See PX4/PX4-ECL#585
I want to add some logic to this (can either be done in this PR or in a follow up PR):

  • when we have a valid terrain estimate use that to set ground compensation flag (e.g. below 1m distance to ground)
  • when mode is Takeoff then activate ground compensation once (EKF has hysteresis so triggering the flag once during takeoff should be sufficient)
  • when mode is LAND then always activate ground compensation
  • do not do compensation when vehicle in landed and not armed

I think this pretty much covers all the cases, what do you think?

@EliaTarasov
Copy link
Contributor Author

EliaTarasov commented Mar 7, 2019

@RomanBapst I agree on the items you want to add. Do you have any test results which are include pr?
Upd:
I checked out PX4/PX4-ECL#585 and tested it with uneven ground.
Landed local_position.z was approx. -0.75m with respect to home.z and gnd_effect_max_hgt was 0.15m.

Logs:

  1. master

master

  1. pr

pr

@EliaTarasov EliaTarasov force-pushed the pr-ground_effect_zone branch from 17df26f to b840fea Compare March 8, 2019 16:34
@EliaTarasov
Copy link
Contributor Author

@MaEtUgR thanks, fixed.

@EliaTarasov EliaTarasov force-pushed the pr-ground_effect_zone branch 2 times, most recently from 1dfb26f to a5c9a27 Compare March 8, 2019 19:18
@EliaTarasov
Copy link
Contributor Author

EliaTarasov commented Mar 10, 2019

@RomanBapst i added the first item from your list:

when we have a valid terrain estimate use that to set ground compensation flag (e.g. below 1m distance to ground)

Is it a correct way?

@@ -1174,7 +1177,13 @@ void Ekf2::run()
}
}

if (range_finder_updated) { _ekf.setRangeData(range_finder.timestamp, range_finder.current_distance); }
if (range_finder_updated) {
if (range_finder.current_distance <= _gnd_effect_deadzone.get()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

@EliaTarasov We should not directly use the range finder data but instead the distance to ground estimate from the estimator. You can just move the activation of the ground effect further down where we publish local position. The code could then look like:
if (lpos.dist_bottom_valid && lpos.dist_bottom < _gnd_effect_deadzone.get() < 1.0f)

@@ -1250,6 +1259,10 @@ void Ekf2::run()
if (vehicle_land_detected_updated) {
if (orb_copy(ORB_ID(vehicle_land_detected), _vehicle_land_detected_sub, &vehicle_land_detected) == PX4_OK) {
_ekf.set_in_air_status(!vehicle_land_detected.landed);

if (_gnd_effect_deadzone.get() > 0.0f) {
Copy link
Contributor

Choose a reason for hiding this comment

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

@EliaTarasov We need to combine this with the distance to ground check. Basically if we have distance to ground we use that otherwise we use the flag from the landing detector.

@EliaTarasov EliaTarasov force-pushed the pr-ground_effect_zone branch from cd7a053 to 8431841 Compare March 11, 2019 12:31
@EliaTarasov
Copy link
Contributor Author

EliaTarasov commented Mar 11, 2019

@RomanBapst i've combined you suggestions but confused of result.
I assume that _gnd_effect_deadzone is a distance to ground in meters and within it we calculate baro innovations as here.
When we use only baro for height estimation we rely on descent speed and therefore always expect to be in dead_zone here.
When we use terrain estimation we rely on distance to ground and enable dead_zone when lpos.dist_bottom < _gnd_effect_deadzone

Is it correct?

Logs:

  1. Land detector
  2. Terrain estimation

They are almost identical, but i expect the second log should display vehicle_land_detected.in_ground_effect below _gnd_effect_deadzone.

@EliaTarasov EliaTarasov force-pushed the pr-ground_effect_zone branch from 8431841 to 4f902d2 Compare March 11, 2019 15:15
@@ -1390,6 +1393,16 @@ void Ekf2::run()
lpos.dist_bottom = _rng_gnd_clearance.get();
}

// update ground effect flag based on terrain estimation
if (lpos.dist_bottom_valid && lpos.dist_bottom < _gnd_effect_deadzone.get()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

@EliaTarasov I suggested to use _gnd_effect_deadzone.get() here but I don't think that makes sense. Should we use a fixed value like 1m or something?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@RomanBapst yes we may but i think it's better to add another parameter for this purpose. So _gnd_effect_deadzone would be both for flag and for barometer innovations,
and say _gnd_effect_distance would be for distance above ground where we may expect such innovations.
What do you think?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@RomanBapst any thoughts?

Copy link
Contributor

Choose a reason for hiding this comment

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

@EliaTarasov Apologies for the delay! Yes, that sounds like a good idea. Let's do those changes and then get this PR in. After this I want to continue taking into account takeoff as well (for the case where we don't have a terrain estimate). I already talked to @priseborough and he is ok with removing the local position dependency in the estimator. I think it's anyway a good idea to not put this kind of logic into the estimator itself but have it reside here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@RomanBapst Great, thanks! I've added the distance parameter.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@RomanBapst Good to go?

@RomanBapst
Copy link
Contributor

@EliaTarasov Looks good, asking the test team to try it.
@PX4/testflights Could you please test fly this on a copter using the following instructions:

  1. Please set the parameter EKF2_GND_EFF_DZ to 4
  2. Do a couple of takeoff and landings in position control and mission.

Thanks!

@jorge789
Copy link

Tested on Pixhawk v2 Cube; Parameter EKF2_GND_EFF_DZ was changed to 4.
It was armed and took-off in Position. During the flight, flight modes were switched to (Altitude and Stabilized) and landed in position. Good in general.

https://review.px4.io/plot_app?log=853b5e1b-9c70-4f87-8af7-eea984ec08ad

Tested on Pixhawk v2 Cube; Parameter EKF2_GND_EFF_DZ was changed to 4.
It was tested in mission mode, armed, take off and land automatically. The flight was good in general there were only some oscillations by air but all good.

https://review.px4.io/plot_app?log=307107cf-b532-45d0-a84c-ec58b2fbdb84

@Junkim3DR
Copy link

Tested on Pixhawk 4 v5;

  • Parameter tested: EKF2_GND_EFF_DZ to 4.
  • Vehicle armed and took-off in position mode.
  • During flight, switched to altitude and then stabilized mode.
  • Landed in position mode.

Pitch and yaw movements were slower than usual besides that it was a good flight.
https://review.px4.io/plot_app?log=7d753f70-2ac4-4f8a-84dc-b6399833626f

Tested on Pixhawk 4 v5;

  • Parameter tested: EKF2_GND_EFF_DZ to 4.
  • Vehicle armed, took-off and landed in mission plan mode (Automated).

No issues were noted, good flight in general.
https://review.px4.io/plot_app?log=f001aac6-6bb7-42e6-a110-ec769c810f49

Tested on Pixhawk 4mini v5;

  • Parameter tested: EKF2_GND_EFF_DZ to 4.
  • Vehicle armed and took-off in position mode.
  • During flight, switched to altitude and then stabilized mode.
  • Landed in position mode.

Good flight in general.
https://review.px4.io/plot_app?log=24f87362-4857-430d-b7b9-9982720340ef

Tested on Pixhawk 4mini v5;

  • Parameter tested: EKF2_GND_EFF_DZ to 4.
  • Vehicle armed, took-off and landed in mission plan mode (Automated).

No issues were noted, good flight in general.
https://review.px4.io/plot_app?log=ff3ba2f9-770a-4ded-b35c-dbee185dba9f

@RomanBapst
Copy link
Contributor

Functionality works as expected. The ground effect flag triggers during the landing phase and when the vehicle is getting close to the ground the baro innovations are subject to a dead-band.

image

@RomanBapst RomanBapst merged commit b3bb625 into PX4:master Mar 21, 2019
@RomanBapst
Copy link
Contributor

@EliaTarasov @hamishwillee We need to document this :-)

@RomanBapst
Copy link
Contributor

@hamishwillee I assume we can put it in the user guide, maybe here?
https://docs.px4.io/en/advanced_config/tuning_the_ecl_ekf.html

@RomanBapst
Copy link
Contributor

PX4/PX4-user_guide#460

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.

6 participants