Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AMC-BLDC: the supervisor needs to manage the motor-hal errors #40

Open
valegagge opened this issue May 12, 2023 · 5 comments
Open

AMC-BLDC: the supervisor needs to manage the motor-hal errors #40

valegagge opened this issue May 12, 2023 · 5 comments
Assignees
Labels
domain-modeling Pertains to model-based design team-five Activity performed by Team FIVE type-board-amcbldc Relevant to the AMCBLDC development

Comments

@valegagge
Copy link
Member

Following the work done here robotology/icub-firmware#360 (comment), we want to update the supervisor in order to manage the motor-hal errors: hardware-overcurrent and hall-sequence-error.

Dod

  1. The supervisor is updated
  2. The code has been generated
  3. The code has been tested.

Note: the test is not simple because this error are hw-related, so we need to find a way to simulate them.

@pattacini
Copy link
Member

pattacini commented May 12, 2023

Hi @valegagge

Just for clarification, in which manner the hardware-overcurrent differs from the overcurrent limitation we have implemented in the architectural model?

Is there a low-level check?

@pattacini pattacini added team-five Activity performed by Team FIVE type-board-amcbldc Relevant to the AMCBLDC development domain-modeling Pertains to model-based design labels May 12, 2023
@pattacini
Copy link
Member

There's also a connection to #15.

@valegagge
Copy link
Member Author

valegagge commented May 12, 2023

Hi @pattacini!

Hi @valegagge

Just for clarification, in which manner the hardware-overcurrent differs from the overcurrent limitation we have implemented in the architectural model?

Is there a low-level check?

The driver calls this callback in case of faults and here sets the overcurrent flag. For this, I'm referring to an hardware-overcurrent, while in the supervisor, we check if the filtered current goes beyond the configured limit.

image

@valegagge valegagge self-assigned this Sep 4, 2023
@valegagge
Copy link
Member Author

Checking the current code of the AMCBLDC board, the External fault is managed by polling instead of on ISR. So I think to implement the same solution for the hardware over current.

See here and here.

Moreover, I verified that in the 2FOC fw, the hardware over current and software over current are notified to the EMS using the same bit in the status message. Therefore I'll adopt the same solution.

In the future, if we want to distinguish the two faults we need to change the can protocol.

I suppose that the callback pwmMotorFault_cb registered here works properly.

@valegagge
Copy link
Member Author

I just write down some notes how to address this issue:

  1. add "HWOverCurrent" in the External Flag struct of the dictionary
  2. update the Fault handler in order to check that flag in addition to the measured current.
    As I said before, We use the same flag to notify the sw and hardware cover current.
  3. perform supervisor's test and fw tests

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
domain-modeling Pertains to model-based design team-five Activity performed by Team FIVE type-board-amcbldc Relevant to the AMCBLDC development
Projects
None yet
Development

No branches or pull requests

2 participants