Arm API Notes

[ennerf]

WORK IN PROGRESS. STILL GOING THROUGH THE EXAMPLES.

Branch with changes: https://github.com/HebiRobotics/hebi-python-examples/tree/ennerf/arm-examples/kits/arm

General API Notes

• hebi.Lookup() always requires sleep(2). Maybe that should just be a default parameter in the constructor?
• lookup returns None if modules were not found. Is there any case where we actually want to continue rather than just throwing an error? The return is often followed by checks if groups is None: throw error()
  • I think the Python API should probably generally throw more errors rather than enforcing explicit checks.
  • same for create_mobile_io when the device is not found
• hebi.util.plot_trajectory() plots linear movements as well. Do we want to keep that?

MobileIO

• orientation returns arOrientation instead of (IMU) orientation. AR is not always available, and some use cases need access to both.
• the mobile wrapper orientation should be able to be passed into the IK method, either directly or via a helper method to turn it into a rotation matrix
  • For now I've added a helper function in ex_AR_kit.py, but it should be moved into the API utils
• phone.get_button_diff(1) == 3: #ToOn is unclear. I assume 3 is some enum, but we should really have some defines for that (or at least have it be something intuitive like [-1, 0, +1])

Arm API - Naming/Structure

• I'd vote for renaming cancelGoal() to clearGoal() to avoid ambiguity when there is no goal
• The ImpedanceController should use the more intuitive names Kp, Kd, Ki rather than damper_gains and spring_gains (see ImpedanceController.m)
• The arm.py file is huge and unwieldy to read. Is there a way to split it up without messing up the import usability?

Arm API - Bugs

• There is a bug that causes the Gripper to be called with aux = [] (called by arm.py::227), which returns False on any updates when there is no active trajectory
• Adding aux states in the teach_repeat_w_gripper example doesn't seem to work. I haven't yet investigated at which level the bug occurs (e.g. Goal implementation vs gripper sending vs state keeping)
• The first half second of the initial goal always results in crazy movement. It looks like it starts the trajectory at an initial state of all zeros (rather than fbk.position)?

Examples

• impedance_controller

  • there were a few logical bugs. It needs to disable position/velocity control and only update the goal once when the button is pressed. Fixed in branch.

• teach_repeat_with_gripper

  • had logical bugs and suffers from arm api bugs. (Has this ever worked?)

• AR_kit

  • I tried porting it, but it'll probably need SciPy if we don't want to implement e.g. matrix multiplications ourselves. I assume that's ok to use as long as we add a note to the Readme to install it?

• All

  • Example copy-pasted the logging line group.start_log('dir', 'logs', mkdirs=True), which I'd expect to create logs/<timestamp>.hebilog rather than dir/logs.hebilog. I may have some MATLAB syntax bias here, but I'd vote for changing it to use named parameters for readability.
  • We should probably add loading of default gains for all kit examples

[ennerf]

I can no longer reproduce the zero-position start bug. I don't know what I ran into there.