Separate RobotBase from MJBotsInterface #31
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
The goal of the parent class is to seperate the MJBots specific code from the robot code. Presumably this begins the process of creating a inheritable kodlab robot interface for better communication and accessibility between classes and a future where different systems could be used (instead of just MJBots).
Using the so called 'dreaded diamond' to implement a class that is derived from both an MjbotsRobotInterface and SimpleRobot example class which are each in turn virtually derived from kodlab::RobotInterface. This version requires building and passing in the robot to the control loop which upcasts the pointer to an MjbotsRobotInterface. Should not break legacy code
The multiple inheritance makes the construction fraught and requires writing two contructors currently. Partly because of the scope of ControlLoopOptions, likely we should make a RobotOption class.
The dreaded diamond led to many issues for writing new robot classes and control loops because it over complicated the construction of them. By composing seperate classes (RobotInterfaceDerived and MjbotsRobotInterface) in MjbotsControlLoops all of those issues are removed. Using the existing shared pointer vectors both classes have access to the JointMoteuses (using upcasting or copying directly, resp.), which is necessary for setting and sending torque commands. Lastly, some states are moteus specific, e.g. pi3hat::attitude and moteus::Mode and are now also housed in moteus_interface_ and will require conversion funcitons to be fed into the RobotInterfaceDerived class.
ShaneRozenLevy
requested changes
Aug 3, 2022
jdcaporale
commented
Aug 3, 2022
|
README.md updated in 4b9c6b3. |
ethanmusser
approved these changes
Aug 3, 2022
jdcaporale
commented
Aug 3, 2022
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.
(Pull Request 2 of 3 in a sequence: builds from PR #30 and originally in PR #22 )
Adds the RobotInterface Class. Its role is to separate MJBots specfic communication and hardware interfacing from robot state for control. The MJBots hardware interface shares ownership of the JointBase/Moteus pointers and uses them for communications and the robot is free to set trques and to be derived to include any future features (limbs, state estimators, etc.).
Also, adds a simple derived robot example.
TODO: