Comments (5)
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.
from icub-firmware-models.
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.
from icub-firmware-models.
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.
from icub-firmware-models.
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.
from icub-firmware-models.
Super!
from icub-firmware-models.
Related Issues (20)
- Update Wrist-Mk2 model – Let the controller deal with left/right + old/new mech HOT 3
- Refactor AMCBLDC prj to expose library components
- AMCFOC – Check resources for running 2 FOC algorithm inside CM4 HOT 2
- AMCFOC – Study how to make the AMCBLDC/Supervisor general enough to cope with 2 motors HOT 1
- Explore ways to support code reusability HOT 4
- Study the gut of the Supervisor HOT 2
- Extend data dictionary to deal with multiple motors – Stint 1 HOT 30
- Refactor AMCBLDC project to rely on external components HOT 1
- AMCBLDC: supervisorTX doesn't handle the overcurrent flag. HOT 6
- Extend data dictionary to deal with multiple motors – Stint 2 HOT 18
- AMCFOC – Refactor the Supervisor motor-independent part HOT 16
- AMCFOC – Streamline block duplication HOT 3
- AMCFOC: refactor motor-specific supervisor to be used with `For Each subsystem` HOT 14
- Inspect and resolve the interaction between `For each subsystem` and FOCInnerLoop HOT 4
- CMSIS routines for `sin`/`cos` are not used in FOC HOT 24
- AMCFOC – Extend to AMCFOC the improvements recently applied to AMCBLDC HOT 2
- AMCFOC – Test the architecture HOT 17
- AMCFOC – Port latest dev from AMCBLDC project HOT 4
- AMCBLDC: Inspect suspect regression in simulation HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from icub-firmware-models.