Dev - #155
Open
vikashplus wants to merge 66 commits into
Open
Conversation
Point cloud utility functions for mujoco [Draft]
… compliance. Envs now overwrite the correct _reset function. Gym compliance is now preserved across the defaulting envs
- gym/gymnasium compatibility doesn't port over when custom reset is provided - we are now recommending a call to super().reset(**kwargs) to get the appropritae return type ensuring compatibility
np.product -> np.prod for np 2.0 compatibility
bump pyh5 and pin numpy
1. FEATURE: Explicitely marks the closure of the trace
2. BUGFIX: Introduces create_datum. create_dataset is updated and is now reserved for adding full datasets (shouldn't be edited later). If appending is needed first create_datum() and then follow it with repeated calls to append_datum().
3. BUGFIX: verify_type is stricter now. It goes beyond checking for root dtypes. It thoroughly checks for type, shapes, keys - even for nested structures. This implies that dict{datum} also needs to maintain its internal keys to support append leading to further consistency
4. FEATURE: Much like rendering of rgb datasets, now trace supports plotting of numerical datasets using a list(grp_keys)_ng and list(list(dataset_keys))_ng
5. Adds multiple tests to check for data consistency and plotting consistency
Collaborator
|
… can be further improved by having a global settings of rnumerical precision throughout the repo
Minor upgrades
dependency update and code alignment
fix time_wall update
…s in robot_config. Currently it was hardcoded to sim so when the definitions in config differend from sim, things didn't line up accurately. Now hardware_apply_controls() also accepts the space in which controls is provided
BUGFIX: Making indexing agnostic to of Robot Config order
# sim_id: ID of the sensor/actuator in the sim
> # hdr_id: ID of the sensor/actuator in the robot_config (hardware) space (robot_config unifies different hardware into a single unified hardware space)
# adr: Address of the sensor/actuator in the individual hardware space (e.g. dynamixel) (This is the address used during communicate with the individual hardware)
MAJOR: REFACTOR: Improve robot space definitions
[fix] render-window crash due to window-deletion; add parse_mjl.py from vive
…eck for existance of 'time' key for sensors
…rry complex data from the hardware into sensordata field of the model. Reply on sensordata field to create obs and obs_dicts
…e 0-d scalars squeeze_dims() previously did a blanket np.squeeze(), which removed every singleton dimension instead of just the (num_traj=1, horizon=1) wrapper added by expand_dims(). Single-value observations (e.g. shape (1,)) were squeezed all the way down to 0-d scalars, which then failed to concatenate with other proprio/obs vectors in get_proprioception() and obsdict2obsvec(). Now only squeeze the leading axes that expand_dims actually added, leaving real data dimensions (and pre-existing scalar rwd_dict entries) untouched.
Robot._resolve_data_ids caches each joint actuator's feedback address as data_id into sim.data.qpos, but computed it with jnt_dofadr (the qvel address). qpos and qvel addresses coincide only while all preceding joints are 1-DOF: any free/ball joint earlier in the model (e.g. a manipulable object defined before the arm) shifts every subsequent actuator's read by the qpos/qvel size difference (freejoint: 7 vs 6). The stale read feeds the velocity limiter in process_actuator(), which re-anchors each command to the wrong joint's position — in practice the arm freezes at whatever pose keeps the misread error small. Observed on anthrohive URDtriosPickPlace-v0 (box freejoint precedes the UR5e): the arm ignored all position targets until this fix.
Extend supported sensors
fix(robot): index actuator qpos reads with jnt_qposadr, not jnt_dofadr
…e base class. So there is no need to deviate away from the get_sensor() signature
…handling of outputs. Better plots
- 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.
… 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).
Vk/consolidate robot - new hardware registery - hardware classes follow base class contracts
FEATURE: Improved path_utils. Better scanning of directories. Better …
This file contains hidden or 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
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.
No description provided.