AMCFOC: Refactor motor-specific supervisor to get around codegen issues

[mfussi66]

This PR addresses #65 and targets the AMCFOC and Common board projects, with a refactor of the motor supervisor.

Objective

Fixing the codegen errors that occur when enclosing the motion controller in a ForEach subsystem, which is useful for driving multiple motors independently.

The problem

The C code generation did not work for the motor-specific supervisor because the function-call triggered subsystems had the trigger inputs of size >1. They are highlighted in the picture below.

Not only it didn't work, it was not even possible to simulate the model.

The solution

Since the logic of the system is essentially a big parallel FSM (finite state machine), a refactor was made to wrap all the blocks in a single parallel Stateflow system, included in the ms2.slx file:

Each single fsm is included, in the same form as before, or functionally equivalent:

The charts run in parallel, aka they all run at the same tick, in the following order:

1. First, fault manager
2. Inputs dispatcher
3. Control mode handler
4. Last, Targets manager

They use local data to exchange information, and local events to trigger transitions between each other:

While it's not easy to find at a glance where data is read/written, the highlighting capabilities of the Simulink GUI can solve all doubts.

Fault manager

Works exactly as before: two parallel charts, one for handling the fault button, and the other for the hardware faults, aka overcurrent check at the moment.

Inputs dispatcher

The inputs dispatcher receives a mega data structure containing all possible types of inputs, and depending on the type of event, it triggers the execution of the related subcharts:

The charts on the inside are stripped-down versions of the ones before: they run only when they are called, then return. See for example the limits handler:

An exception to this pattern is the control mode set, which just triggers an event read by the Control mode handler.

Control mode handler

This is almost a copy-paste of the one already implemented, but with some subtle changes:

• when a change of ctrl mode causes a setpoint change, the related event directly addresses the Targets Manager chart. This is a required pattern when working with local events in parallel charts
• There are no more functions called isCtrlModePos(), isCltrModeCurrent() etc : now there is just isReqMode(mode)

Warning: The custom C functions (rtw_enable/disable_motors) were disabled for the purpose, they will be added back asap.

Targets manager

The targets manager is a new addition to the charts, and it reuses part of the SetPointHandler logic to handle targets both from the control mode handler and outside:

Note that we can use the function in(ControlModeHandler.<mode>) to check which state the ControlMode Handler is in (and therefore the mode of the board) and write the proper setpoint.

We also implement a graphical function to experiment with it, which probably is more efficient than an interpreted matlab function.

Tests

Proper harnesses will come in the future, but for now there is a test model called test_supervisorV2.slx that confirms the correct operation:

MATLAB_Bepv9RBCB2.mp4

Code generation

The code generation now works successfully, both in C, C++11, and inside the for each.

Note that this is not supposed to be a deus ex machina system, and can be changed in the future. Though now it's a bit simplified.

[pattacini]

Awesomely done!
I've only changed the base branch to devel, which was equal to master by the way.