ADVRHumanoids / ROSEndEffector

ROS End-Effector package: provides a ROS-based set of standard interfaces to command robotics end-effectors in an agnostic fashion
Apache License 2.0
27 stars 6 forks source link

[hal2] xbot2 features evaluation for ROSEE #57

Open torydebra opened 4 years ago

torydebra commented 4 years ago

Hi all, I open this issues under Luca's suggestion to start a discussion about what we would like to have from xbot2 for ROS End-Effector.

I have never really used xbot1 neither, so sorry if I list something that is already there or that has not any sense for xbot2.

I list here all the features, we can open new issues (maybe on xbot2_wip ?) for the specific ones if they sound interesting.

I mention all the people who I see to be around xbot2_wip, feel free to add more if it is the case @liesrock @lia2790 @alaurenzi @DavideAntonucci


HAL2 as modular component detached from xbot2

You are already aware of this, ROSEE only needs a HAL2 and not all xbot2


Single concrete HAL for any simulated ROS robot in rviz/gazebo

In ROSEE now we have a DummyHal which can be used for any robot in simulation. I would like to have a generic concrete HAL like this. I mean, I do not want to create a concrete HAL each time I want to simulate a robot with ROS. Each concrete is the same because we communicate to the simulation always with ROS topics. Instead, I want to create a concrete HAL when I have a real hand, because it is really specific and I need more that simply publishing to ROS topics to let the hand moving. Like we have for HERI II now. This have sense?


Motor/Actuator as a different component from Joint

This caused lot of issues to ROSEE, due to underactuated hands. It would be nice to have the device motor separated from the device joint. What would be the differences in practice? Theoretically they are similar because both need set and get for Pos,Vel,Eff. But I was thinking that a joint should have the set in someway "private": the user cannot set a joint, but only a motor. The set for a joint is needed only when we are in simulation, to impose the underactuation. Following this principle, I would put a private set also for motor. The difference is that a motor will have also a setReference, which can be used by user. XBot::Joint I see that this one has always associated a motor-side state, is this changed in xbot2?


Custom ROS messages

I see that in xbot1 it is used a xbot_msgs/JointState ROS msg. I think it is nice to have the possibility to use other custom messages (included the standard ROS sensor_msgs/JointState). For example, xbot jointState has always joint and motor state, but we do not have a motor associated with a joint each time.

Note it is possible to parse any ROS message without having the .msg (and the generated header) at compile time! (ros_msg_parser, successor of ros_type_introspection)


Forward kinematics and collisions

Xbot1 had fk, but it has also a method to check for collisions from meshes? Like moveit do, with FCL. Is there something in hal2? We need collisions when looking for pinches.

P.S. Xbot1/2 considers the tag in urdf for joints?


Updates

None (for now...)

lia2790 commented 4 years ago

Hi Davide, for what I can understand, I think the points that you addressed

For the others points, I can not give some feedback since I miss relevant details for that.

liesrock commented 4 years ago

Hi @torydebra, thanks for the issue and the details, I am back on this: I believe we have most of the features requested in your issue here except for the collision avoidance.

The way to proceed is the following from my point of view: you should try to understand the workflow and the feature of the on-going work on XBot2 by following the tutorial/example package provided by @alaurenzi https://github.com/ADVRHumanoids/xbot2_examples

You can then open specific issues either on the xbot2_examples repo or the xbot2_wip one.