Support of 7 joints in the mk3 hand #179
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Apr 12, 2021
some changes were needed on:
- EOtheEncoderReader which now manages up to 7 encoders
- EOtheMotionController which now manages up to 7 joints and the new eo_motcon_mode_mc4pluspmc
- EOtheCANmapping whuch now supports more than two values for eObrd_caninsideindex_t
- Controller and Motor which:
- manage the case of 7 joints (before they were 4 only)
- now the two types MC_ACTUATION_t and MC_MOTOR_HARDWARE_t to manage what previously was
coded w/ HARDWARE_2FOC, HARDWARE_MC4p and UNKNOWN. in this way we have an actuation,
the ACT_TYPE_MC4pPMC, which can have 4 motors of type HARDWARE_MC4p and 3 of type HARDWARE_PMC.
- for motors of type HARDWARE_PMC we have actuation through CAN messages.
- ETH callbacks such as eoprot_fun_UPDT_mc_joint_config() etc which manage the case eo_motcon_mode_mc4pluspmc
moreover, the macro EOTHESERVICES_customize_handV3_7joints is defined in order to increase the RAM required
for managing 7 joints instead of 4
SHA-1: 182201c of 3/25/21 11:16:05 AM
the connector J13 is now named correctly (it was wrongly called J11)
… tests it is activated by macro EMBOT_HW_BSP_PMC_emulates_SNSR_PZM
…es more virtual motors
by undef of TESTRTC_IS_ACTIVE
… inside code enabled by EOTHESERVICES_customize_handV3_7joints
…stomize_handV3_7joints is defined. otherwise the code is exactly the same as for the case of 4 joints.
…e (not eo_motcon_mode_mc4pluspmc
…ant bit of ID of CAN protocol to represent the joint number
ems -> 3.39 mc4plus -> 3.32 mc2plus -> 3.23
marcoaccame
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Aim of the PR
This PR is part of a set of PRs which adds support to manage the movement of the 7 joints of the mk3 hand.
The new MC mode is offered by the pair
mc4plusandpmcand is hence nicknamedeomn_serv_MC_mc4pluspmc.In order to do that, some features in
icub-firmwareandicub-firmware-sharedare required in order to:eomn_serv_MC_mc4pluspmc,The first feature adds changes to the data structures transmitted over ETH and hence has required an increase of the MN protocol version.
To limit the effect of the latter feature (which needs more RAM) the changes have been been conditioned to the macro
EOTHESERVICES_customize_handV3_7joints, which is defined so far only by the projectmc4plus.handv3.uvprojx.For this reason the FW of the standard
ems,mc4plusandmc2plusboards does not have much impact.Description of the changes
The
mc4plusdirectly moves the four joints of the hand in open close mode (thumb, index, medium, pinky) by controlling 4 DC motors. That is standard behaviour for themc4plus.However, the
mc4plusalso manages other three joints (thumb metacarpus, thumb rotation, index adduction) which are actuated by piezo electric motors driven by thepmcboard.As such, the
MControllerinside the mc4plus board has been extended to contain data structures for 7 joints/motors rather than for 4 as it happens so far.The extension of data structures to hold more entities (and hence use more RAM) and the addition of some extra functions is enabled by macro
EOTHESERVICES_customize_handV3_7joints.The aim is that with macro
EOTHESERVICES_customize_handV3_7jointsbeing not defined theemsandmc4plusdon't compile some parts of code, don't use additional RAM and don't change much their behaviour.Associated PRs
This PR is a part of a set of related PRs:
icub-firmware-shared: it adds required data structures;icub-firmware: it adds the FW of the mc4plus in a dedicated project calledmc4plus.handv3.uvprojx;icub-firmware-build: it adds the FW of the recompiled versions of theems,mc4plus,mc2plus;icub-main: it adds capability of parsing xml file for the modeeomn_serv_MC_mc4pluspmc;robots-configuration: it adds the xml files for the experimental setupwristmk2_handmk3.Tests
Two kind of tests were done. Both of them were successful.
iCubGenova04robot so that we can be sure that the FW produced foremsandmc4plusstill works fine. The test showed that the robot, in itsiRonCubversion is able to move the head and the upper arms using the new versions ofmc4plusandems.yarprobotinterfaceand of theyarpmotorguifor the case of emulated piezo motors and emulated magnetic encoders.Final comment
This PR adds support for the movement of the new hand and does not add any new features to the standard robots. We have now yarprobotinterface running properly for the new hand with 7 fingers. But we also made sure that the robots keep on working as before.