Feature/rl framework integration#858
Conversation
There was a problem hiding this comment.
This has just been changed yesterday in #842
What is this?
| <arg name="viz" default="false"/> | ||
| <arg name="torqueless_mode" default="false" description="start without torque, for example for testing the falling detection"/> | ||
| <arg name="tts" default="true" description="Whether to enable text-to-speech"/> | ||
| <arg name="tts" default="false" description="Whether to enable text-to-speech"/> |
| <arg name="walking" default="true" description="start walking" /> | ||
| <arg name="torqueless_mode" default="false" description="start without torque, for example for testing the falling detection"/> | ||
| <arg name="tts" default="true" description="Whether to speak" /> | ||
| <arg name="rl_motion" default="true" description="Whether to use the RL motion system instead of the regular one" /> |
There was a problem hiding this comment.
What is the regular one in this case. It seems to replace the other one.
| <arg name="teamcom" default="false" description="Whether the team communication system should be started" /> | ||
| <arg name="vision" default="true" description="Whether the vision system should be started" /> | ||
| <arg name="world_model" default="true" description="Whether the world model should be started"/> | ||
| <arg name="rl_motion" default="true" description="Whether to use the RL motion system instead of the regular one" /> |
| def get_velocity_data(self): | ||
| def get_velocity_data(self) -> np.ndarray: | ||
| assert self._joint_state is not None | ||
| if self._joint_state_indices is None: |
There was a problem hiding this comment.
This my might be dangerous in some situations if e.g. some joint states are missing later on and the array gets shifted. Probably it's fine with the way we communicate with the motors, but I don't think the optimization safes that much compared to a potentially hard to debug issue.
| @@ -0,0 +1,59 @@ | |||
| import numpy as np | |||
| from handlers.ball_handler import BallHandler | |||
There was a problem hiding this comment.
Is this needed for the mjlab walk?
| def allowed_states(self): | ||
| allowed_to_move = self._robot_state_handler.is_walkable() and np.any(self._command_handler.get_command() != 0.0) | ||
| return allowed_to_move | ||
| return self._robot_state_handler.is_walkable() |
There was a problem hiding this comment.
We might need to think a bit about the robot states and how we integrate the kick. Also how we trigger a state change in the HCM for the kick. But we need to think about the kick interface for that. A topic based solution seems fine, but I have some concerns on how we go back to the walking after the kick for example. Especially how exactly we integrate this with the hcm.
3 participants
Summary
integrate the mujoco playground trained walk in the bitbots_rl_motion framework
includes some changes from #832
Checklist
pixi run build