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

[WIP] Intuitive manual position control by mapping stick input to acceleration #12072

Closed
wants to merge 21 commits into from

Conversation

MaEtUgR
Copy link
Member

@MaEtUgR MaEtUgR commented May 25, 2019

Describe problem solved by the proposed pull request
This is a first draft for a more intuitive manual position controlled flight by stick. Mapping the stick input to velocity generally results in a too agressive flight behavior so often tight acceleration limits have to be applied which result in a too long braking distance and a percieved delay in executing stick inputs.

Describe your preferred solution
Mapping the stick inputs to an acceleration looks promising to solve a big part of the listed problems. It feels more intuitive and guarantees gentle vehicle behavior when being gentle on the sticks while allowing to brake hard in emergency cases by pulling the stick all the way to the oposite side of flight direction.

This task requires changes to the position controller to track an
acceleration setpoint which me and @bresch are working on.

Test data / coverage
This is a draft and not yet ready to fly on a real vehicle. I'm currently testing in SITL with a joystick to see what changes to the position controller make sense to execute these setpoints.

Additional context

resolves #12999

@LorenzMeier
Copy link
Member

Awesome!

@hamishwillee
Copy link
Contributor

This is just Position mode MC? When this goes in, can you remind me that we will need to update https://docs.px4.io/master/en/flight_modes/position_mc.html (and a few other pages)

@MaEtUgR MaEtUgR force-pushed the acceleration-based-input branch 3 times, most recently from bae9428 to 43ec3a5 Compare May 28, 2019 06:53
@Pedro-Roque
Copy link
Member

Pedro-Roque commented May 29, 2019

This sounds good! But on the other hand we need a good estimation of the acceleration.

I can try to help with this!

@xdwgood
Copy link
Contributor

xdwgood commented May 31, 2019

Looking forward to its merger, in fact many customers want this feature...Better control feel, better PX4 😃

@MaEtUgR MaEtUgR force-pushed the acceleration-based-input branch from a859733 to 9697af2 Compare June 1, 2019 15:57
@MaEtUgR MaEtUgR force-pushed the acceleration-based-input branch 2 times, most recently from 3448d87 to 8953724 Compare June 2, 2019 13:52
@MaEtUgR
Copy link
Member Author

MaEtUgR commented Jun 2, 2019

This is just Position mode MC?

@hamishwillee Yes, it's thought as a replacement option for the current implementation of the manual position mode. At first it will for sure not be default. I will inform you about the behavior and configuration options. Thanks for thinking ahead 👍

This sounds good! But on the other hand we need a good estimation of the acceleration.

@Pedro-Roque Certainly would be good to have a useful acceleration estimate but this pr produces acceleration setpoints to be used in a feed-forward manner for the attitude setpoint generation and is not dependent on a good acceleration estimate.

many customers want this feature...Better control feel, better PX4

@xdwgood Exactly what I've seen as well. Thanks for the confirmation from your side.

@MaEtUgR MaEtUgR force-pushed the acceleration-based-input branch 2 times, most recently from 5518761 to b7d2b21 Compare June 2, 2019 19:05
@Pedro-Roque
Copy link
Member

This is just Position mode MC?

@hamishwillee Yes, it's thought as a replacement option for the current implementation of the manual position mode. At first it will for sure not be default. I will inform you about the behavior and configuration options. Thanks for thinking ahead 👍

This sounds good! But on the other hand we need a good estimation of the acceleration.

@Pedro-Roque Certainly would be good to have a useful acceleration estimate but this pr produces acceleration setpoints to be used in a feed-forward manner for the attitude setpoint generation and is not dependent on a good acceleration estimate.

many customers want this feature...Better control feel, better PX4

@xdwgood Exactly what I've seen as well. Thanks for the confirmation from your side.

Right, I understood now how you do it after going a bit through the code. Sounds good! Will keep an eye on it

@MaEtUgR MaEtUgR force-pushed the acceleration-based-input branch 5 times, most recently from 11c670b to 93a2bdf Compare June 7, 2019 11:35
@MaEtUgR MaEtUgR marked this pull request as ready for review June 7, 2019 11:56
@MaEtUgR MaEtUgR force-pushed the acceleration-based-input branch from c359999 to a4162e3 Compare June 7, 2019 12:16
@MaEtUgR MaEtUgR requested a review from bresch June 7, 2019 12:17
@MaEtUgR MaEtUgR force-pushed the acceleration-based-input branch 2 times, most recently from f594580 to 966f0cb Compare June 8, 2019 14:20
@MaEtUgR
Copy link
Member Author

MaEtUgR commented Oct 22, 2019

After rebasing unsuccessfully and realizing that it will probably not be mergeable anytime soon because of risk I'm breaking this down into small pieces. Sorry @Stifael for not listening in the first place (#12072 (comment)).
The first part that should be easy to review is here: #13247
I'll update you with the follow-ups.

@MaEtUgR MaEtUgR changed the title Intuitive manual position control by mapping stick input to acceleration [WIP] Intuitive manual position control by mapping stick input to acceleration Nov 5, 2019
MaEtUgR added a commit that referenced this pull request Nov 21, 2019
This issue was found by @khabir and reported over slack.
It resulted from the split up of the big pr #12072 into #13262.
I took over the interface while the internal states still stayed the
hard to understand internal ones. One of the follow up refactors will
fix this completely and the entire legacy setpoint restore block can
be removed.
dagar pushed a commit that referenced this pull request Nov 21, 2019
…13557)

This issue was found by @khabir and reported over slack.
It resulted from the split up of the big pr #12072 into #13262.
I took over the interface while the internal states still stayed the
hard to understand internal ones. One of the follow up refactors will
fix this completely and the entire legacy setpoint restore block can
be removed.
@MaEtUgR MaEtUgR added this to the Release v1.11.0 milestone Dec 11, 2019
@MaEtUgR MaEtUgR force-pushed the acceleration-based-input branch from 7811355 to 331ce88 Compare December 14, 2019 17:21
When the acceleration setpoint went to more than on g downwards
the horizontal thrust setpoint generation was screwed up.
@LorenzMeier
Copy link
Member

I'm closing this.

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.

[Feature request] Altitude prioritization in ALTCTL