-
Notifications
You must be signed in to change notification settings - Fork 13.7k
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] Multicopter Controllers Muxing #14754
Conversation
This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions. |
@Pedro-Roque This still seems really interesting. Any progress/testing? |
@bresch TBH I didn't proceed any further since I didn't know how much interest it had, and maybe it would be better to focus on fixing other things first (the SITL is one of those I want to fix once I'm "free"). You think it would be interesting to have this for v1.12 ? |
If possible, yes. |
Hi @Pedro-Roque and @bresch , I've been looking for something like this for very long. I'm very interested. I think that this would be very interesting since several model-based control techniques outputs the thrust of the motors (or, equivalently, the wrench in the flying body). For that purpose, sometime ago I did this. I wasn't sure of the development though, since a modification of the mixer module was required and I was afraid of messing something up. |
@PepMS , if you disable the rate controllers ( {0} option ), then you need to set individual motor speeds directly - with all the Pro's and Con's that come with it. Essentially you would get this chain for a position-control MPC: User Setpoint -> {MPC position control} -> {0} -> {0} -> Mixers , since MPC will output motor controllers directly |
I see. Would you need a special mixer for that? To which uORB topic should the controller publish so that the commands are applied directly to the motors? |
You would have to send the inputs to the same topics (unless you want to extend the chain to {PX4 mixer, custom mixer 1, custom mixer 2, ... , 0}. The analogy would be the same in that case. |
Sorry to insist on this. So in case in the example you said, where you are omitting the attitude and rate controller, the MPC position control should publish to the topic that the original rate controller was publishing, right? Which at the same turn is the input to the mixer. Is that correct? |
Yes exactly. But the mixer could also be disabled in the same way, leading the MPC to control directly the actuators. |
That would be the most appropriate thing for my case. How should we proceed? I could take over, but I certainly need some advice with the development. |
If there are more people interested, we could do a quick Zoom call on this and distribute some tasks? |
Takeaways:
|
@@ -178,5 +178,6 @@ | |||
"workbench.statusBar.feedback.visible": false, | |||
"yaml.schemas": { | |||
"${workspaceRoot}/validation/module_schema.yaml": "${workspaceRoot}/src/modules/*/module.yaml" | |||
} | |||
}, | |||
"C_Cpp.errorSquiggles": "Disabled" |
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'd like to see if we can keep them in certain circumstances.
A configurable low-level control chain
The objective for this WIP PR is to modularize the low-level control chain so that it is easier to integrate different controllers for rate / attitude / position on multicopters. The framework shall be extendable to other systems afterwards, but I will start with these. We hope that this makes it easier for everyone to incorporate novel controllers into the stack, as well as provide researchers with an easy way into PX4 to test their own control approaches.
Describe your solution
Involved devs/users: @dagar @Jaeyoung-Lim @bresch @PepMS
The solution will be a muxing of which low-level controllers are active for a specific flight. The user selects (or doesn't, hence leaving default) the controllers for MC Position, MC Attitude and MC Rate that he wishes to use on a given flight, before the vehicle is armed. For all runs, the default PX4 controllers are initiated and ready, but are not running in parallel - they stay dormant but will takeover once the user leaves OFFBOARD mode.
Gdrive Doc (ongoing discussion moved there):
https://docs.google.com/document/d/1bexM6KeLv73wtiiRvYTqrCHi-HpvmC5YHYHy5CTjibQ/edit?usp=sharing
On the one hand, this allows for sandboxing of controllers under test, providing a safer environment to test new research. On the other hand, I will also provide basic templates that will allow for anyone to implement their own control laws on the low-level system and test them in SITL.
NOTE: this will be WIP for at least a few months. However, interested devs are welcome. I will be working on this at my own pace.