AMCFOC: refactor motor-specific supervisor to be used with For Each subsystem

[mfussi66]

The idea of the AMCFOC motion controller is to be referenced in a For Each subsystem. This kind of subsystem allows calling the block multiple times, depending on the dimensionality of the input/output signals. In this way, we can use the same functions for multiple motors.
However, this type of subsystem relies on the internal function-call subsystems to have the trigger signal of width=1. The motor-specific supervisor is full of these triggers. It is therefore necessary to replace this kind of logic with an equivalent one, most likely with a less modular state machine, that allows us to resolve this limitation and enable the full features of the supervisor.
After this, it will be possible to create unit tests for the motor-specific supervisor.

[mfussi66]

Currently the Motor Supervisor (MS) looks like this:

Many signals have been disabled so that we could have only one triggering the execution of the charts. However, some charts have been disabled because their existence we could cause a data dependency violation, and therefore an error.

Therefore, it might be necessary to do a whole refactor of the MS, and not a partial one.

Due to the number of output events and triggered subsystems, we can see that the Simulink blocks basically behave like a big stateflow chart. I think we could create a single chart that incorporates the functionalities of these blocks.

While modularity might be impacted, I think it's just a matter of presentation, as stateflow charts can be modularized with parallel charts and sub-charts.

[pattacini]

While modularity might be impacted, I think it's just a matter of presentation, as stateflow charts can be modularized with parallel charts and sub-charts.

Agree 👍🏻

[mfussi66]

While modularity might be impacted, I think it's just a matter of presentation, as stateflow charts can be modularized with parallel charts and sub-charts.

This is the idea I am following. A group of parallel charts, with the following priority order (descending):

1. Fault Manager
2. Inputs Dispatcher
3. Control Mode handler

1. The fault manager works exactly in the same way as it is in the AMCBLDC
2. The inputs dispatcher merges the following blocks:
   • Events dispatcher
   • PID handler
   • Limits handler
   • SetPoint Handler
     After setting limits, PIDs and so on as internal variables, the dispatcher goes back to home, waiting for new inputs
3. The control mode handler is a copypaste of the AMCBLDC one

What is interesting to do, is the ability to pass events between charts, and knowing which state a specific chart is in.

See for example the SetpointHandler. I can use the following syntax to check which control mode we are in, so that we set the proper target:

[mfussi66]

I added another parallel chart to handle the fact that a new setpoint could come either from the dispatcher or the control mode handler, but it's super simple, since its task is only to copy the values towards the Targets output:

Note that the chart always writes the setpoint at the moment, no matter the type of event. This is of course a huge simplification, and it can be subject to change as requested.

I created a simple test and the setup of the control mode seems to be respected so far:

MATLAB_RnDGVdVdLx.mp4

[pattacini]

Nice!

[mfussi66]

Latest commit correctly allows to set the target, and it seems like the model can run in simulation inside the ForEach.

[mfussi66]

Interestingly, the code generation in C works for the motion controller with the new supervisor 🎉
It needs to be thoroughly tested through harnesses, of course.

Anyway, at the moment, I'm encountering a difficulty on how to use the initial configuration.:
The Common project, since it implements a single motion controller, benefits from having a single initial config struct.
However, the AMCFOC project requires two instances of initial configuration, and it would be nice if the initial configs were different from each motor. I'm not really sure how I can initialize the variables according to the initial configuration within the For Each subsystem. Maybe it will be useful to ask in the Matlab community.

[pattacini]

Interestingly, the code generation in C works for the motion controller with the new supervisor 🎉
It needs to be thoroughly tested through harnesses, of course.

Super 🚀

Anyway, at the moment, I'm encountering a difficulty on how to use the initial configuration.:

Can't we have an array whose elements are of a structured type like the one we're currently employing?
Perhaps, within the for loop, we can retrieve the index and use it as the selector for the array?

Maybe it's too simplistic.

[mfussi66]

Perhaps, within the for loop, we can retrieve the index and use it as the selector for the array?

That can be done!
I wanted to avoid adding extra inputs to the motion controller block, because it might have made the resulting C functions more complex. But since we would be dealing with constant values, maybe the codegen is smart and can create an intuitive and simple solution.

[pattacini]

I wanted to avoid adding extra inputs to the motion controller block,

After all, the initialization param can be an extra input w/o loss of generality.
We can see this together.

[mfussi66]

Opened a PR here #68 to wrap up the work on this specific issue and document the changes.

[pattacini]

Completed via #68!

[mfussi66]

Updating this issue to show that the new motion controller works with two motors 🎉

The simulation is painfully slow, so I cannot show a video, but you can see the screenshot down here, in which I send two different Iq targets simultaneously. The Iq feedbacks are logged on the right, and after a while I press the fault button:

cc @pattacini @Nicogene

[pattacini]