Impedance control ex

[GogiPuttar]

Added 5 impedance control examples, namely:

• Fixed: A task-space pose controller implemented entirely using force control via the (PID) impedance controller.
• Cartesian: Locks onto a particular end-effector position while having some compliant orientation.
• Gimbal: A gimbal that locks a specific end-effector orientation, while keeping the rest of the arm compliant.
• Floor: The end-effector is free to move but can't travel below a virtual floor. To further simulate sliding on the floor, see force_control example.
• Damping: The end-effector behaves as 3-different damped systems (overdamped, critically damped, and underdamped), at 3 different heights.

[GogiPuttar]

Should I remove/rename T-arm's HRDF and gains file? This is not a standard model given on the website.

[GogiPuttar]

Ready for review again!

[GogiPuttar]

Would really like your opinion on whether the connection checking loop should be in the script, or should be incorporated in the hebi_util::create___FromConfig functions. Though I have implemented the former, I am in support for the latter, even though it is one more (unnecessary) layer.

[GogiPuttar]

FYI:

• ex_impedance_control_cartesian, ex_impedance_control_gimbal, ex_impedance_control_fixed are exactly the same save for the name of the config file and comments

• ex_gravity_compensation_toggle, and ex_impedance_controller_damping both incorporate retrieving and altering a plugin using a pointer

• gripper examples have only been renamed but not altered. After I have a look at how the gripper is implemented in the API, I would like to have it streamlined with the mobile_io such that there is hebi_util::createGripperFromConfig function that handles all the funny business

• ex_teach_repeat has been changed significantly to match the python API

• I would like to remove the instructions sent to the mobile_io since they seem to be redundant as layouts for the examples involve different emojis and other stuff. They are also very finicky to align properly.

[iamtesch]

Huh -- before the changes, we were at line 86 at this point. Code length isn't the most important metric, but if done well (and still appropriately commented) shorter code can improve readability. I had expected the examples to get a bit shorter by using the layout and config files, so I was a little surprised.

I think a bit of this is just slightly different style, and some is a printing out more error info when loading configs, but I'm curious whether you see anything I'm missing, or if you have ideas to improve this. I'd love to eventually get these 110 lines down to something simple and relatively self-documenting like the following, but in the meantime I wonder if we could maintain the readability, but shorten some of the boilerplate?

auto config = Config::create('file', ErrorMode=PrintAll);
if (!config)
  return 1;
auto arm = Arm::createWithRetries(config);
auto mobile_io = MobileIO::createWithRetries(config);
if (!arm || !mobile_io)
  return 1;

[iamtesch]

Looks good overall! A few suggestions on one file that I think could apply through the examples.

Overall, I know it isn't always possible/easy with changes such as these, but these type of changes can be more difficult to review when the result is essentially 11 new example files and 3 deleted files. If possible to add more incremental/single purpose changes in the future, that'd be awesome and quick to get in. For example (this is a bit overkill, but that's ok)

PR 1: rename files (check! insta-approval-merge! Plus, makes future diffs easier, because the git diff engine isn't looking to determine if the two AR kit examples should be diffed or treated independently)
PR 2: add the config files and remove old HRDF files (another super quick approval/merge -- although may require some unfortunate temporary changes to the example files)
PR 3: Replace arm creation with the "createFromConfig" function in all the examples
PR 4: Add the "createMobileIOFromConfig" helper function, and replace mobile IO creation with this in all the examples
PR 5: Add new examples
PR 6: Various example cleanup/editing

More work overall to open the PRs, but breaks down the review incrementally, and allows stuff to (a) start getting in before everything is perfect, and (b) ends up with a more careful/detailed review (it's easier to make sure nothing accidentally gets through when you're looking at a diff changing the arm construction, rather than a completely new example file)

[iamtesch]

Would really like your opinion on whether the connection checking loop should be in the script, or should be incorporated in the hebi_util::create___FromConfig functions. Though I have implemented the former, I am in support for the latter, even though it is one more (unnecessary) layer.

Ah -- sorry I didn't respond to this sooner!

Yeah, I think a simple util wrapper with a createWithRetry function could be nice, but it might make more sense to be in the API directly. Let's do this in a separate PR, though.

[iamtesch]

FYI:

• ex_impedance_control_cartesian, ex_impedance_control_gimbal, ex_impedance_control_fixed are exactly the same save for the name of the config file and comments
• ex_gravity_compensation_toggle, and ex_impedance_controller_damping both incorporate retrieving and altering a plugin using a pointer
• gripper examples have only been renamed but not altered. After I have a look at how the gripper is implemented in the API, I would like to have it streamlined with the mobile_io such that there is hebi_util::createGripperFromConfig function that handles all the funny business
• ex_teach_repeat has been changed significantly to match the python API
• I would like to remove the instructions sent to the mobile_io since they seem to be redundant as layouts for the examples involve different emojis and other stuff. They are also very finicky to align properly.

Yeah, I am OK with removing the redundant instructions for those examples that use mobile IO!

[GogiPuttar]

Ready for review again!

[GogiPuttar]

One last dance

[iamtesch]

Closing, as the content here has been separated into and merged in several other PRs, and the remainder is currently in #101