-
Notifications
You must be signed in to change notification settings - Fork 13.3k
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
Conversation
// Allocate | ||
_actuator_sp = _actuator_trim + _mix * (_control_sp - _control_trim); |
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.
@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.
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.
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?
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.
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.
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. |
7423538
to
ad1948b
Compare
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. |
989cb7c
to
e535990
Compare
4acf1b2
to
cce735f
Compare
Testflown on this bunch of illustrious VTOLs today: 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. @dagar @jlecoeur, or anybody else: a review would still be very much appreciated! |
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 |
Wasn't correctly updated during a rebase.
…ing param Makes it a bit easier to configure. Reversing by setting MIN > MAX is still supported.
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>
ca94835
to
04ae90e
Compare
Flash overflow resolved and rebased on master. |
Isn't having 2 mechanisms to reverse an output going to be potentially confusing?
Then in the old mixing world we already have a REV parameter per ouput (eg PWM_MAIN_REVx). |
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. |
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
|
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 am trying to check out this PR but it gives error, |
@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. |
Thank You. |
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!! |
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)? |
This brings the ideas from #18701 and #18558, based on the valuable input from @sfuhrer, @dagar and others.
Details:
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)Tiltrotor example:
![qgc_actuators_tiltrotor_sitl](https://user-images.githubusercontent.com/281593/144608930-da8a717e-5103-464f-9b85-9d7967ec92ed.png)
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.