[FEATURE REQUEST] Context manager for dynamixel bus

[ntjess]

Is your feature request related to a problem? Please describe.

Currently, manual interactions with a device will entail something like:

bus = DynamixelBus(...)
# Make some servos
# Do some operations

# De-torque servos
bus.close()

However, if any of the operations result in an exception, the bus will never be closed and the servos may still have torque enabled. This may cause errors restarting the code.

Describe the solution you'd like
A context manager might solve some of these issues quite nicely:

with DynamixelBus(...) as bus:
  # Make some servos
  # Do some operations
# If an error occurred, the __exit__ method will safely close the bus

The tricky part would be determining the best way to clean up the devices constructed within the context manager scope. I was thinking something like

def close_servo(_servo):
  _servo.torque_enable.value = False

with DynamixelBus(...) as bus:
  servo = ...
  bus.exit_callbacks.append(partial(close_servo, servo))
  # Do the things

Then, the __exit__ function of BaseBus will dispatch each callback in exit_callbacks when the context manager is out of scope.

Describe alternatives you've considered
I have been placing some tentative clean-up code in a try-catch block so far.

Additional context
Add any other context or screenshots about the feature request here.

[ntjess]

Alternatively, the YAML file for a device could contain instructions on how to safely shut it down. This sequence of specified operations could be executed by the bus for each connected component.

[sonelu]

I don't think it is a problem to add context management for DynamixelBus or even to the parent class BaseBus to support that scenario.

But be aware that the thinking about activating the torque is the following:

• BaseRobot constructor only creates the buses, devices, joints, syncs, and the JointManager
• when the BaseRobot's start is called it opens the buses, and the devices (which practically reads the current registers of all devices); devices' torque is not affected
• the BaseRobot calls the JointManager to start(); this triggers the activation of all joints associated with the JointManager; it is at this moment that the torque is activated provided that:
  • joints have an activate register
  • joints have auto set to True (which is default)

Stopping the torques happen when:

• the BaseRobot stop is called; it will first stop the JointManager, that deactivates the joints if they have an activate register and auto is True
• then stops the syncs and closes the buses

The complication arises from the fact that there are many threads using the bus: the JointManager handles the joints and all sync threads that replicate read and write values to devices. So it is physically impossible to put everything under one context manager.

All IO operations are under try block and they are intercepted and logged to the logging instead of raising exceptions.