Skip to content

Vk/consolidate robot#174

Open
vikashplus wants to merge 8 commits into
devfrom
vk/consolidate_robot
Open

Vk/consolidate robot#174
vikashplus wants to merge 8 commits into
devfrom
vk/consolidate_robot

Conversation

@vikashplus

Copy link
Copy Markdown
Owner

No description provided.

…e base class. So there is no need to deviate away from the get_sensor() signature
- robohive/robot/hardware_base.py — new HARDWARE_REGISTRY/SENSOR_POSTPROCESS dicts and @register_hardware(type_name, sensor_postprocess=None) decorator (works on classes or factory functions).

- robohive/robot/hardware_franka.py, hardware_robotiq.py, hardware_optitrack.py, hardware_realsense.py, hardware_realsense_single.py, hardware_dynamixel.py — each now conforms to hardwareBase (adds recover(), fixes get_sensors() naming/keys to the neutral pos/vel/effort contract) and self-registers via @register_hardware(...).

- hardware_optitrack.py also had a pre-existing broken import (darwin.darwin_robot...) fixed to robohive.robot.hardware_base.

- hardware_dynamixel.py's Dynamixels was previously non-functional. Added a real adapter. It will need a consolidation effort to reconsile all dynamixel based robots
- hardware_init, hardware_get_sensors, hardware_apply_controls, hardware_close collapsed from hardcoded if/elif chains on interface['type'] into uniform registry-driven loops.
- New Robot.hardware_reset(reset_pos): a dedicated blocking/large-displacement reset path (each hardware class runs its own min-jerk trajectory), replacing the old hardware_apply_controls(..., is_reset=True) overload.
- Fixes a real bug where reset indexed by hdr_id (counts all actuators) while the ctrl vector it built only counted qpos-type actuators — silently misaligned on any device mixing qpos and tendon actuators (e.g. arm+gripper).
- get_visual_sensors() now duck-types hasattr(device['robot'], 'get_frame') instead of asserting interface['type'] == 'realsense', so UVC/webcam-style cameras (rgb-only, no depth) no longer crash it.
- adr renamed to hdr_adr throughout (configure_robot(), camera calibration) — now consistently documented as a physical hardware address (motor ID, RTDE join- adr renamed to hdr_adr throughout (confe raise NotImplemented → raise NotImplementedError(...) with descriptive messages.
- Added robot_cls = kwargs.pop('robot_cls', Robot) extension point so downstream repos never need to subclass/swap Robot.
- Added optional init_qpos param — if provided, used directly as self.init_qpos; otherwise falls back to today's auto-computed mid-actuator-range behavior. Warns if hardware-backed with no explicit init_qpos (homing to an implicit pose is likely unintended on real hardware).
- Swapped the startup call from self.step(np.zeros(...)) to self.reset() + self.forward(), so hardware now goes through Robot.reset()'s min-jerk hardware_reset() on env construction instead of jumping straight to a raw zero-ctrl command from wherever the robot currently is.
@vikashplus
vikashplus requested a review from andreh1111 July 24, 2026 22:55
… internally (to route hardware envs through min-jerk reset) instead of self.step(zeros). Since reset() is often overridden by subclasses, this exposed a latent ordering bug across ~20 env files: they computed a task-specific self.init_qpos after calling super()._setup(), but by then super()._setup() had already triggered the first reset() using a stale/default init_qpos. In relocate_v0.py this stale pose left the hand and object permanently in collision, and the env's collision-retry logic in reset() recursed forever (RecursionError).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant