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
QuadPlane: Precision Landing(v2) #11339
Conversation
ArduPlane/quadplane.cpp
Outdated
#endif | ||
|
||
if ((poscontrol.state == QPOS_POSITION2 && plane.auto_state.wp_distance < 2) || | ||
(doing_precision_landing && target.length() < 2)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is similar code in control_loiter (lines 1231-1257) which was previously written that also controls landing state transitions. Wasn't sure to put it there or here - where there is a QPOS_LAND_DESCEND transition already defined.
@@ -2177,6 +2243,23 @@ void QuadPlane::vtol_position_controller(void) | |||
} else { | |||
pos_control->set_xy_target(poscontrol.target.x, poscontrol.target.y); | |||
} | |||
|
|||
#if PRECISION_LANDING == ENABLED | |||
// run precision landing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not fully around pos_control, but it seems that when I override the it with pos_control->set_xy_target(target_pos.x, target_pos.y);
there is less authority to move the craft to the target location - it can hover for many seconds approx 3m away from target coordinates horizontally, delaying the Q_POS_DESCEND
transition
thanks for this work! |
No problem, I'll do this tomorrow |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added lots of nitpick comments, but this is really pretty good! I look fwd to hearing about testing on a real vehicle
ArduPlane/quadplane.cpp
Outdated
if (land_icengine_cut != 0) { | ||
plane.g2.ice_control.engine_control(0, 0, 0); | ||
float height_above_ground = plane.relative_ground_altitude(plane.g.rangefinder_landing); | ||
if (doing_precision_landing) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why the different descent rate handling for precland to normal land?
also, it omits the ICE control in precland case
ArduPlane/quadplane.cpp
Outdated
pos_control->set_alt_target_from_climb_rate(-land_speed_cms, plane.G_Dt, true); | ||
case QPOS_LAND_FINAL: { | ||
cmb_rate = compute_descent_rate(0.5f, doing_precision_landing); | ||
pos_control->set_alt_target_from_climb_rate_ff(cmb_rate, plane.G_Dt, true); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
again, why change to _ff, and why change rate at all?
ArduPlane/quadplane.cpp
Outdated
#endif | ||
|
||
if (poscontrol.state == QPOS_POSITION2 && | ||
((plane.auto_state.wp_distance < 2) || (doing_precision_landing && target.length() < 2))) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we could abstract this into a function that gets the XY distance to target
ArduPlane/precision_landing.cpp
Outdated
int32_t height_above_ground_cm = current_loc.alt; | ||
|
||
// use range finder altitude if it is valid, else try to get terrain alt | ||
if (rangefinder_alt_ok()) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not use the existing Plane::relative_ground_altitude() function?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm quite sure we shouldn't do this - and should stick to passing rangefinder data through to the library here.
If we were to drop down to using the terrain database the errors could be really quite large. Better to be safe here and solely rely on rangefinder data IMO - at least for an initial cut.
@tridge this branch has previously been kept up to date but merging master into it. Not sure how to squash/rebase this easily. Any advice on what to do? I don't have much experience rebasing. I'll work through the rest of your notes in the meantime |
1433142
to
d158944
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good now!
@lukedempsey is this going to be merged soon? |
I poked tridge during the dev call, and he said it needs a rebase, and he might have a try.... |
Is this still being worked on? Is there a timeline for this being merged? |
Hello,
I have halted my work on this feature due to feature creep. The changes I made successfully implemented precision landing in quad plane however when I attempted a pull request the ArduPilot team had numerous refactors, optimizations and other improvements they wanted to add before they would allow it to be merged. I was not comfortable implementing the myriad of changes as I no longer have a platform I can test my changes on.
Thanks,
Jonathan L Clark
On Monday, October 28, 2019, 11:50:40 AM PDT, CBMUniversal <notifications@github.com> wrote:
Is this still being worked on? Is there a timeline for this being merged?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I'm not responsible for the plane code but in general a good way to escalate a PR (give it a push towards getting merged) is to add the "DevCallTopic" label (or ask someone like me, tridge, amilcarlucas, etc to add it) and then attend the weekly dev call. I know the timing of the weekly call can be difficult for some locations... but just trying to give some help on the process. mumble server used for weekly dev call: http://ardupilot.org/dev/docs/ardupilot-mumble-server.html |
Thanks for the info but I am currently out of the UAV space. I was working for a UAV company when I worked on precision landing but I have moved on and I am now in a different industry.
Thanks,
Jonathan L Clark
On Tuesday, October 29, 2019, 06:32:10 PM PDT, Randy Mackay <notifications@github.com> wrote:
I'm not responsible for the plane code but in general a good way to escalate a PR (give it a push towards getting merged) is to add the "DevCallTopic" label (or ask someone like me, tridge, amilcarlucas, etc to add it) and then attend the weekly dev call. I know the timing of the weekly call can be difficult for some locations... but just trying to give some help on the process.
mumble server used for weekly dev call: http://ardupilot.org/dev/docs/ardupilot-mumble-server.html
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I should be clear; I have no intention of completing all of the requested changes and features that were recommended when I submitted this pull request. I personally feel that those requests are outside the scope of my task; implementing precision landing in quadplane and represent scope creep. |
1e30d2a
to
c131054
Compare
I have rebased this on master |
Any updates on this? I'm trying to build tree precLand, i've also tried c131054c1a5959233a078725691ddad2070cb016 i'd love to get this running and help out if possible edit: turns out it was just a problem with the way i was cloning the git. i was doing git download and doing git submodule udpate --recursive after, just doing git clone --recursive fixed this. coming across this in the precland tree next edit2: again a problem with how i was setting up my build environment (didnt update submodules after changing trees, a folder name had a space in it and make didnt like that, etc etc) got it to compile and put it onto a cubeBlack board. Accidentally compiled and uploaded arducopter first, worked great, compiled arduplane after and missionplanner wont pick up any heartbeats now. |
c131054
to
f4915c0
Compare
I've rebased this on master, having already merged some of the patches (which needed @rmackay9 's approval) I've also fixed several things I spotted - the update rate we pass into AC_PrecLand on construction must be the same as that in the scheduler table; the library itself takes the minimum of that and the scheduler loop rate to determine its buffer sizes. There are still several more issues to cross here. |
0c08c96
to
bc74036
Compare
Not really the estimator's job to run the prediction step
Just because we're getting in-range readings from the rangefinder doesn't mean we have a non-zero de-glitched value. This change also clarifies that unless we pass "true" in for rangefinder_alt_valid then the altitude is unused.
bc74036
to
14fd82a
Compare
@peterbarker Hi peter! Just wondering if there is anything i can help with to have this feature implemented into quadplane |
i think if @tridge and @peterbarker have both massaged the code thru forced-pushes AND tridge has written 'looks good' , then this is simply a merge-on-ci-pass now. |
I'm removing MergeOnCIPass. At the very least the scope of rebasing required would mean this would need another thorough review. |
Is this going to be merge to master anytime soon? |
+1 |
Are there at least any updates on whether this will be added to the next release of arduplane? |
+1 i would be also very interested in getting this into mainline |
i've decided to do this with lua scripts for flexibility: #26380 |
This is a carry-on from @jonathan84clark's original PR (#10378) - adding the precision landing functionality to quadplanes.
I have got it landing consistently in SITL - I'm yet to do a hardware test.
I haven't squashed commits etc yet, as I still have a couple of questions about the code, I'll add them as comments below.