Study and sketch a first proposal for extending the Supervisor_RX – Stint 1 about icub-firmware-models

[pattacini]

Hi @mfussi66

I think you made some progress recently on this task.
You may write up a brief summary of the latest ideas and then we can close the issue.

[mfussi66]

Today I gave a go at this activity by first moving around the components in the supervisor-rx.
I tried to identify subsystem that can be considered motor-specific, and for which we need different configuration parameters and targets.

The subsystems in question, highlighted in yellow, are:

• Limits handler
• PID handler
• Control Mode handler
• Setpoint handler

Moreover, I think the "Overcurrent" FSM should be moved from the Supervisor-rx state handler, so that it can be used for each motor.

[mfussi66]

Proceeding with the analysis and experimentation, I thought it could also be useful to move the FSM dedicated to raising faults outside the SupervisorRx State Handler.
This is because (I think) a fault such as overcurrent could occur for each motor independently from the other.
Therefore, I grouped the FSM with the other subsystem, calling it Fault Manager. This Fault Manager could also be used as a wrapper for the i2t protection logic.

Additionally, I imagine the configuration step should allow for two different sets of motor configs, limits, pids.
To this end, a data structure called e.g. Actuator containing:

• limits
• motor config
• pid params

could be passed to each block that sets the related parameters. This container could then be used to propagate the parameters to other functions (e.g. FOC, Fault Manager).

Important note: the changes I'm making to the blocks are not proposed as official refactoring, but they are just sketches of ideas.

[mfussi66]

While studying a possible extension of the dictionary (#54), I was able to encapsulate FOC and outer controller seamlessly in a single Motor Controller model. The latter also needs the Supervisor_RX motor specific layer, highlighted in yellow in the previous comment. It could be done in such a way:

The Motor-specific layer of the supervisor can have its output interface operate with no problem with the Motor controller.
However, on the input side, it is dependent on the State Handler and the CAN Message Handler. All the CAN parameters and message events are sent to the respective state machines. In its current state, the Motor-specific block does not have an unbearable amount of entry-points, but I think it would be nice to devise a way to simplify them. See the picture below to see what I mean.

In the end, all the motor-specific components could be referenced together in a single Simulink model, so that it will be possible to iterate over them or selected by switching (this is not possible within the System Composer), like so:

I think that in the refactor we could design an input interface for the motor-specific layer of the sup-rx, so that it becomes a common way to send high-level commands to a motor controller.
The CAN Msg handler can be specific to the AMC-BLDC, while a bespoke system could be built for the AMC-FOC.

[pattacini]

Super!