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

Support for addressing ICC communication in MC #431

Merged
merged 16 commits into from
Oct 24, 2023
Merged

Support for addressing ICC communication in MC #431

merged 16 commits into from
Oct 24, 2023

Conversation

marcoaccame
Copy link
Contributor

@marcoaccame marcoaccame commented Oct 24, 2023

In brief

This PR changes prepares support for sending MC frames not only to actuators on CAN locations (boards such as foc or amcbldc) but also to actuators placed on the ETH board. This latter is the case of the amc board which has an actuator on its second core that can be reached by using inter core communication (ICC).

So far, no functionality is added: only code refactoring.

In more details

The code for the transmission of the frames related to MC is moved from the file Motor.c into objects of a dedicated namespace where it is possible to discriminate between CAN and ICC destinations.

As an example, we send a velocity PID message with the following code:

    // ICUBCANPROTO_POL_MC_CMD__SET_VELOCITY_PID    
    embot::app::eth::mc::messaging::sender::Set_Velocity_PID msg {{o->mlocation}, {Kp, Ki, Kd, Ks}};
    msg.transmit();  

The constructor of the message surely accepts the values to send {Kp, Ki, Kd, Ks} but it also accepts a location that can be either on CAN or on ICC. It is inside the .transmit() method that eventually the transmission is directed towards CAN or ICC:

static bool transmit(const Location &des, const eOcanprot_command_t &cmd, Former f)
{
    bool r {false};
    if(true == des.isCAN())
    {
        r = tx2can(tocanlocation(des), cmd);
    }
    else if(true == des.isICC())
    {
        embot::prot::can::Frame frame = toprotcanframe(des, cmd, f);
        r = tx2icc(des, frame);
    }  

    return r;            
}

Where for the CAN we have a call to the EOtheCANservices object we have always used:

bool Command::tx2can(const eObrd_canlocation_t &canloc, const eOcanprot_command_t &command)
{
    return eores_OK == eo_canserv_SendCommandToLocation(eo_canserv_GetHandle(), const_cast<eOcanprot_command_t*>(&command), canloc);               
}

And for ICC we have for now an empty function that we shall fill in a later PR with a call to a embot::app::eth::theICCservices object.

bool Command::tx2icc(const Location &des, const embot::prot::can::Frame &frame)
{
    //#warning TODO: fill embot::app::eth::mc::messaging::sender::Command::tx2icc() which adds a frame in the ICC queue
    embot::core::print(frame.to_string());
    return true;
} 

Tests

I have tested the code and successfully moved a motor on three different setups using amc, ems and mc4plus boards.

Mergeability

Following the above tests the PR can surely be merged.

Associated PRs

There is a PR for the binaries:

Further work

  • I will add support in icub-firmware-shared / icub-main to describe the location of an actuator to be on ETH and I will enable the code now shadowed by YRI_uses_MC_foc_actuator_descriptor_generic.
  • I will add the embot::app::eth::theICCservices object in the amc board to transmit and receive frames towards its second core and also in the amc2c code to manage communication w/ the amc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant