The generated EMPC is not giving the same results as MPC

We have modelled a Quadcopter linear state space plant , we were able to tune the MPC for a specific operating point and got our desired results , now we continnued to generate a Explicit MPC using our MPC model , but the EMPC is not giving the same results , its behaving too much different . what could be the reason

Answer 1

[Umar]

Hi @Mayank, I came across your post about the Explicit MPC issue with your quadcopter controller, and I think I might be able to help you figure out what's going on.So you've got your regular MPC working great for your quadcopter at a specific operating point, but when you convert it to Explicit MPC, it's behaving completely differently. This is actually a pretty common issue, and the good news is it's usually fixable.The most likely culprit is the parameter range specification. When you generate an Explicit MPC, you need to define ranges for every single controller state, not just your plant states. For a quadcopter, that's your 12 states (positions, angles, and their velocities), but also any disturbance model states, noise model states, and the last manipulated variable values. If any of these ranges are too narrow or incorrect, the EMPC will either return errors or behave unpredictably.Here's what I'd suggest you try first. Run your working implicit MPC in open-loop simulation with typical reference signals and disturbances that you'd expect in real operation. Log all the controller states during these runs and see what ranges they actually cover. Then when you specify the ranges for your Explicit MPC, make them at least as large as what you observed, maybe even a bit larger to be safe. The documentation is pretty clear that underestimating these ranges will cause problems.Another thing to check is whether you used the simplify command when generating your EMPC. If you did, that could introduce approximations that make it behave differently. Try generating it without simplification first to see if it reproduces your implicit controller's behavior exactly. Once that's working, then you can experiment with simplification if you need to reduce the number of regions.Also, during runtime, check the status output from mpcmoveExplicit. If states are going outside their specified ranges, the controller will just hold the last manipulated variable values and give you an error status. That would definitely explain why it's behaving so differently.For a quadcopter specifically, you've got fast dynamics and a decent number of states and inputs, so the parameter ranges really need to be spot on. The angles, angular rates, positions, and velocities all need their ranges properly defined around your operating point.Let me know if you try these suggestions and whether they help. If you're still having issues, it might be helpful to compare the two controllers side by side with identical initial conditions to see exactly where they diverge. Hope this helps you get it sorted out. *Technical Addendum*:A few more specific things that might be useful as you troubleshoot. When you're setting up your ranges, consider using the generateExplicitRange function to create the range structure properly. This ensures you're covering all the necessary parameters including reference signals and any measured disturbances if you're using them.When you run your EMPC, pay attention to the Region output in addition to the status. This tells you which polyhedral region the controller is operating in. If you're getting unexpected behavior, it could be that the controller is jumping between regions in ways you didn't anticipate, or not finding valid regions at all.One thing about quadcopters with 12 states and 4 inputs is that the number of polyhedral regions can grow really quickly. If you have too many regions, it can cause computational issues or make the controller behave erratically. You can check how many regions were generated after creating your EMPC.Also double-check that your linearization point (the operating point you mentioned) is actually included within the ranges you specified. Sometimes people set ranges that don't quite capture the nominal operating point, and that causes the controller to behave strangely right from the start.