-
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
Multicopter mixer saturation handling strategy #7920
Conversation
@eyeam3 Please also try this PR on the Falcon Vertigo if you have time. |
not sure if an additional mixer is needed for quadplanes, unless people are very happy with the current multi-copter mixer. My personal opinion agrees with what @bresch is suggesting to have attitude highest priority to allow full attitude control even at zero thrust (which is currently not the case). However I know that opinions tend to differ sharply and depends a lot on the use case (someone who flies a racer would definitely prefer full attitude control at anytime). |
Right, I mainly want people to understand the possible level of flexibility we have here. It would be easy to have a couple different implementations that extend MultirotorMixer and only make minor changes. Would unit tests help verify intended mixer functionality and any edge cases? |
Hi @dagar! Sure I can help. I have already study the mixer some time ago (and corrected some bugs), and I was planing to simplify the code in the next weeks with one of my students. I think that the code is very complicated, and it would be nice to better understand how it evoluted. Sometimes I think that a really simple mixer (with no priorities) would perform better, but it is difficult to say. Sometimes altitude should have larger priority, sometimes attitude, so maybe no priority would work.. Many will say that's not the way. My idea was to test in simulation many scenarios and compare performance, but I have only experience with quads and I would need help with VTOL. |
It seems to me that (at least at a certain point) prioritizing altitude over attitude would be pointless. When the vehicle is at a 25 percent bank angle there seems to be little point in increasing thrust to gain altitude. I think it would be much more efficient to prioritize the attitude and as soon as we are level try altitude. @AndreasAntener thoughts? |
@dagar should we have @PX4TestFlights test this PR? |
I think I hit that problem as well recently: https://logs.px4.io/plot_app?log=6c4e8474-63dc-4a54-b2ca-9f9ee05566e0 @mrpollo I think we should first do more SITL/HITL testing, before putting this on a vehicle. If you are brave enough, then sure, flash it! :) But keep the kill switch ready. |
@PX4TestFlights Could you please do a careful test with kill switch ready? |
couple flights with the pixracer (V4) full outdoor test: |
@diegoeck would a mixer unit test be helpful or should we do it within a larger simulation? How would you compare performance or identify failures? |
I can perform the same test i did before, it is repeatable and quite obvious when it happens. Just need to wait untill the weather becomes a bit calmer. Expected for this weekend. |
I tested this as well, first in HIL and then on a quad with pixracer. I mapped aux1 to the previous behavior to switch in-flight (see branch manual_input_rework_mixer_rework, which is on top of #7940). Tested:
Logs:
Observations:
Conclusion: I'm confident flying this, it behaves as it should, but I can't say that I covered all the corner cases. |
We will be flying this this weekend and will duplicate the behavior in #7871 |
Unassigned @PX4TestFlights, reassign if needed. |
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.
We tested the PR and it seems to improve the behavior.
Log: https://logs.px4.io/plot_app?log=fd726ed3-219d-4e5d-8d4f-79557d4b4730
Although there was less wind it was clear that it handles much better at extreme roll angles (we normally set a 25 degree limit)
You were faster! 😄 I want to share with you the only reason why I did not make a pr for my version yet: While the logic behind this calculation is pretty simple and increases performance drastically you also have to consider flying safety. As long as the vehicle is in a normal state and the actuators effectuate in the desired way it only helps. But as soon as there is something wrong this logic can make a bad situation like unstable flight a lot worse like uncontrolled full throttle shootout. Maybe I'm overcautious but I wanted to find a solution to this problem before proposing a change like this. Now you were faster and I'm at least not responsible for the crashes 😉 @dagar I think a mixer unit test would make a lot of sense to try and cover all the rare extreme situations which are hard to reproduce in real flight but can still happen. |
@MaEtUgR I'm fine contributing to natural selection :) |
@bresch I like your joke xD I totally agree and just didn't want to strike the ideology which I read out from the old implementation. At least not by default. As I say probably my thinking was too cautious. On topic: We did some tests today with the new mixer on a 450 and a 210 racer and for LOS (line of sight) attitude controlled flight it reacts as expected a lot better when having low throttle. You can also hear the motor speeds of the racer reacting very fast to change attitude when not giving any throttle similar to KISS FC and co. Yaw tracking still has room to improve, I think you concentrated on roll pitch here right? I would have some logic to test also for yaw boosting. The thing I found strange is I did a test flying the racer FPV (first person view) with live video and there you can do a lot more acro stuff because you can easily see the orientation also when being high up and further away. In these tests when I went off the throttle in acro mode the racer got nearly uncontrollable and sometimes even flipped. Don't get me wrong it feels better than before but not completely as I was expecting coming from other race controllers... I have to investigate the logs tomorrow to see if I can find out why exactly that happened. In principle it could be an idle motor speed problem or alike... |
… saturation handling
23bb41e
to
6e58cbc
Compare
- fmu: in case of _mot_t_max==0 _airmode was not set in the mixer - px4io: param_val is a float
A new parameter
Thanks @bkueng ! |
this avoids calling param_get() on every loop iteration.
Let me think about a way we might be able to achieve this without introducing vehicle type specific parameters in every single output module. |
I added the remaining output modules already here: https://github.com/bkueng/Firmware/commits/pr-multi-mix-sat. @bresch can you pull the branch? @dagar Yes, a nice solution would indeed be good here. I was thinking that the Linux, Snapdragon & Sim drivers can just be merged. The linux driver already supports multiple backends. |
@bkueng Done |
I gave this PR a test today with a quadcopter and after two successful flights I had one flight where things went wrong resulting in a gentle crash. I'm not certain that the issue was caused by this PR but I wanted to post the log here in case it is helpful. After taking off I went full throttle and full pitch forward in manual mode. After building up some speed I then let of the controls and switched to position mode. At first it looked like it was doing a good job of recovering, then it started to quickly drop. The motors were still running and the attitude was controlled, but despite putting the throttle stick all the way up the thrust wouldn't go high enough to maintain altitude. Issues I see in the log: 2: Shortly after switching to position mode the commander reported a loss of local position and switched to altitude mode. I have no idea why this happened. Although the altitude estimate seems fairly accurate the "Local position Z" plot seems to think that the vehicle was ascending all the way up until it crashed. Log here: |
After going through the new mixing strategy for roll and pitch the mixer then uses the old reduction-only approach for yaw. This means that yaw will still be totally uncontrolled for low throttle. Would it make sense to use the new mixing strategy for yaw as well, possibly with a limit so that yaw can only make a small adjustment to thrust? |
Hi @nanthony21 and thank you for testing this PR. By investigating the log, I can see that your crash is most likely due to divergence in the EKF solution. The throttle is in fact cut by the altitude controller since the estimator reports that the drone is climbing (you can see that in the first graph of review.px4.io that the estimated height, in blue, increases much more than the baro and GPS measured altitudes). From the EKF repost, it looks that:
Here is the full EKF report: What I can't tell you is the cause of the initial velocity innovation growth. IMU vibrations? Bad GPS? Maybe @RomanBapst could give further explanations. |
If not in air-mode the mixer is not able to apply positive boosting and roll_pitch_scale is recomputed to apply symmetric - reduced - thrust. This has the consequence to cut completely the outputs when the thrust is set to zero.
This is correct, and yes we can extend this, for example by adding another value for the |
After having some issues just after back-transition with a standard VTOL, I found that the problem came from the multicopter mixer.
Since after back-transition the wings can still produce quite a lot of lift with high AOA and high-lift wings, the multicopter thrust is close to zero and the motors are directly saturated when trying to compensate attitude errors. In this special case, the initial 'boost' technique - a gain applied to the thrust - is ineffective:
thrust * thrust_increase_factor
is also close to zero...The 2nd issue highlighted by @sanderux in #7871 is that when the altitude control is active, the thrust saturates the outputs and attitude control becomes sloppy.
I made several passes to first simplify the code and finally rewrite the saturation handling process in order to get rid of the arbitrary boost gains and make the attitude control the highest priority.
Before implementing in PX4, I first made a python script to simulate the different cases, you can try here:
https://gist.github.com/bresch/8ea4232452bc64de1ed780bcfbee3564
Be aware that I never tested this PR in reality and that the mixer code is critical. Be careful when testing!