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

Dynamic control allocation for VTOL & others #18776

Merged
merged 56 commits into from
Dec 25, 2021
Merged

Conversation

bkueng
Copy link
Member

@bkueng bkueng commented Dec 3, 2021

This brings the ideas from #18701 and #18558, based on the valuable input from @sfuhrer, @dagar and others.

Details:

  • handle reversible motors
  • adds separate servo range reversal params (bitset) for simplified configuration
  • adds trim + slew rate configuration
  • adds support for multiple matrices in control_allocator. This is used for the existing VTOL control modules.
  • adds control surfaces + tilt configuration. The tilt captures the physical properties, like min and max tilt angles and direction of tilt. Motors can be assigned to a tilt. For tiltrotors, this is then used to automatically update the motor axis and disable non-tiltable motors during fixed-wing flight (see example UI below).
  • generalizes and extends ActuatorEffectiveness:
    • classes can be used hierarchically. For example a VTOL can include motors + control surfaces.
    • adds updateSetpoint callback method to allow it to manipulate the actuator setpoint after allocation (e.g. to add flaps or any kind of non-linear control)
    • handle motor stopping (disable existing vtol logic to manipulate pwm's directly)
  • handle standard vtol + tiltrotor
  • adds support for rovers (with a fixed effectiveness - this can later still be a bit generalized)
  • adds 6DOF vectored thrust UI, used and tested with the UUV gazebo model
  • performance on F4 running a vtol (400hz): 4KB more RAM, interestingly ~1% less CPU, and doing matrix inversion @ 10Hz uses about 1% CPU.

Tiltrotor example:
qgc_actuators_tiltrotor_sitl

There's still a few more to be added, like tailsitter or tiltable MC's. I also intend to make the motor thrust axis a bit more configurable in the UI, but likely this goes along with some UI changes.

Test flown on a tiltrotor (convergence) - there's still a couple of details to iron out, but it generally works nicely.

We still need to define the control surface torque convention (which we can use to then fill out the constraints table), but I leave that up to others to decide.

See commit messages for further details.

// Allocate
_actuator_sp = _actuator_trim + _mix * (_control_sp - _control_trim);
Copy link
Member Author

Choose a reason for hiding this comment

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

@jlecoeur what was the original intent for _control_trim? My use here is to add an offset to an actuator, but the _control_trim logic leads to undesired effects, and I did not just want to remove it w/o knowing the background.

Copy link
Contributor

Choose a reason for hiding this comment

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

Linearization around a specific actuator state. In a linear system the equation above reduces and trim could be removed. However in a non-linear case --for example a tiltrotor-- it is required.
What are the undesired effects?

Copy link
Member Author

Choose a reason for hiding this comment

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

Makes sense. For example I added a trim of 0.2 to the right aileron for a FW setup, that resulted in a roll=pitch=0.2 control trim, which then overall resulted in an aileron setpoint of -0.2410.
Sounds like we need both then, as it's 2 different use-cases.

@jlecoeur
Copy link
Contributor

jlecoeur commented Dec 3, 2021

@bkueng and @sfuhrer should I review?
I just read that you introduced two matrices for VTOL, I fear that this defeats the purpose of effectiveness matrix inversion -- almost back to the former mixer system right?

@sfuhrer
Copy link
Contributor

sfuhrer commented Dec 3, 2021

@bkueng I pushed some additional VTOL fixes. de380c4 shows one way to handle the throttle allocation for tiltrotor without needing to change too much on the legacy mixing system. Happy to discuss other ideas.

@sfuhrer
Copy link
Contributor

sfuhrer commented Dec 3, 2021

@bkueng and @sfuhrer should I review? I just read that you introduced two matrices for VTOL, I fear that this defeats the purpose of effectiveness matrix inversion -- almost back to the former mixer system right?

Yes it's two matrices. We chose that approach to be able to bring in dynamic control allocation without the need to change the whole VTOL control pipeline. Benefits compared to the legacy mixing system: much easier setup without the need to recompile, enables actuator failure handling and improves tiltrotor control by taking into account the motor tilts.
The step to an unified effectiveness matrix is a much bigger step that will help us to get rid of a lot of vtol specialties all over px4, but a user would not notice a lot, as the interface doesn't have to change.

@sfuhrer
Copy link
Contributor

sfuhrer commented Dec 10, 2021

@bkueng and @sfuhrer should I review?

Hi @jlecoeur , yes would be cool if you could review. We're adding smaller fixer here and there while we go through all the vehicle types and test them in SITL and real hardware, but the core algorithm/concept will likely not change drastically anymore unless we find something.

@bkueng
Copy link
Member Author

bkueng commented Dec 10, 2021

@bkueng and @sfuhrer should I review?

You're welcome to review, yes.

I also added a 'Custom' effectiveness that serves as a catch-all. I think everything should be possible now, except for helicopters, and some mixers that mix in RC aux channels.

qgc_actuators_custom

@sfuhrer
Copy link
Contributor

sfuhrer commented Dec 21, 2021

Testflown on this bunch of illustrious VTOLs today:
image
FunCub Standard VTOL: https://review.px4.io/plot_app?log=118268e4-5bfa-462a-88d5-63543afe6d82
Convergence Tiltrotor VTOL: https://review.px4.io/plot_app?log=0c3141ee-407d-4147-9d3f-5b89c06fb116
Xvert Tailsitter VTOL: https://review.px4.io/plot_app?log=f1bab1e5-4e73-49c4-ae73-56be56c8ebdc

All flew fine in hover and fixed-wing modes without too much rate controller tuning, though we could in general tweak the FW rate defaults a bit (less FF, more P and I). This is though not particularly related to this PR.
The tiltrotor (dynamically updated matrix depending on combined tilt) and the tailsitter flew better than I ever saw them, on the standard VTOL no difference was noticeable.

@dagar @jlecoeur, or anybody else: a review would still be very much appreciated!

@jlecoeur jlecoeur self-requested a review December 22, 2021 08:13
@dagar
Copy link
Member

dagar commented Dec 22, 2021

I'm still working through this, but in the meantime we have a small flash overflow on fmu-v2. https://github.com/PX4/PX4-Autopilot/runs/4606740563?check_suite_focus=true
Screenshot from 2021-12-22 10-58-52

bkueng and others added 11 commits December 23, 2021 10:03
preparation for dynamic control allocation, where we won't have MAIN vs
AUX anymore (at least for the generic frames).
…nd hover thrust

In the tiltrotor case, beside an F_z thrust setpoint also a F_x setpoint must be passed
to the allocator as the matrix has non-zero thrust-x effectiveness when tilts are applied.

Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
- only normalize rpy for MC matrices
- for thrust use the 3D vector, so it works for FW and tilt rotors as well

This keeps MC unchanged.
…n sign

- horizontal control surfaces: up=positive deflection
- vertical control surfaces (rudder): right=positive deflection
- mixed (V-Tail): up=positive deflection

Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
…que_setpoint

Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
…s enabled

Signed-off-by: Silvan Fuhrer <silvan@auterion.com>
@dagar
Copy link
Member

dagar commented Dec 23, 2021

Flash overflow resolved and rebased on master.

@dagar
Copy link
Member

dagar commented Dec 23, 2021

Isn't having 2 mechanisms to reverse an output going to be potentially confusing?

  • output reversed if MIN > MAX
  • per output group REV bits (eg PWM_MAIN_REV)

Then in the old mixing world we already have a REV parameter per ouput (eg PWM_MAIN_REVx).
Can we keep PWM_MAIN_REVx instead?

@dagar
Copy link
Member

dagar commented Dec 23, 2021

One of the bigger takeaways I had from the discussion in #18558 was the handling of control surfaces by type and constraining torque appropriately (eg left vs right aileron).

Is there something else planned to do this with the GUI?

EDIT: I think I found it.

@dagar
Copy link
Member

dagar commented Dec 25, 2021

It took me a while to go through this, but overall it looks good and I'd like to get it in before it gets any bigger or harder to rebase or we run out of flash again, etc.

notes/questions/comments

  • I'd still like to revisit the reverse configuration (Dynamic control allocation for VTOL & others #18776 (comment))
  • control surface constraints handled firmware side, so that it's still possible to safely configure things directly without the GUI
  • per output trim (eg PWM_MAIN_TRIMx)
  • I'm hoping we'll ultimately be able to consolidate quite a lot of this into something more generally configurable rather than carrying every possible airframe specialization
  • can we try to do these things more incrementally going forward?

@dagar dagar merged commit 98d7067 into master Dec 25, 2021
@dagar dagar deleted the control_allocation_vtol branch December 25, 2021 01:06
@mengchaoheng
Copy link

some idea in the book "Aircraft Control Allocation" maybe can help you, the author provides some simulation files which can also be downloaded at https://github.com/mengchaoheng/aircraft-control-allocation.git

@Jawad-RoboLearn
Copy link

I am trying to check out this PR but it gives error,
fatal: couldn't find remote ref refs/heads/control_allocation_vtol
exit status 128

@Jaeyoung-Lim
Copy link
Member

@Jawad-RoboLearn The branch no longer exists from the PR since the branch was deleted after the merge. The commit is merged to the master branch, so you can check out there.

@Jawad-RoboLearn
Copy link

Thank You.

@mengchaoheng
Copy link

some idea in the book "Aircraft Control Allocation" maybe can help you, the author provides some simulation files which can also be downloaded at https://github.com/mengchaoheng/aircraft-control-allocation.git

I have fixed bugs in the source code of this reference book, which can be found in my repository. The qcat from Ola Härkegård's is very helpful!!
@bkueng

@VTOLDavid
Copy link
Contributor

Wich motor gain matrix will result for a quadcopter in deadcat configuration (Front and rear motors same distance to CoG in x axis but different in y axis)?

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.

None yet

8 participants