search

osrf / drcsim

Repository for the DRC project.
18 stars 7 forks source link

Update AtlasSimInterface as BDI evolves the robot control behaviors #337

Closed osrf-migration closed 11 years ago

osrf-migration commented 11 years ago

Original report (archived issue) by David Conner (Bitbucket: dcconner).

The API and built in ATLAS behaviors included in AtlasSimInterface should be updated to evolve along side those being upgraded by Boston Dynamics

osrf-migration commented 11 years ago

Original comment by Thomas Koletschka (Bitbucket: thomasko).

AFAIK the gazebo api is not planned to be supported by BDI anymore

osrf-migration commented 11 years ago

Original comment by David Conner (Bitbucket: dcconner).

Yes, that's my understanding of current intent.

I'm making the request that the simulation is kept consistent with robot to simplify testing and allow us to run as much code as possible both places without modification. Just posted thread for discussion on DRC forums.

osrf-migration commented 11 years ago

Original comment by Maurice Fallon (Bitbucket: mauricefallon).

David, Thomas, Have you heard any response on this?

I notice that the basic names of the joints in drcsim doesn't match those is the real robot. The URDF of the multisense is completely different from the simulated one.

This is what BDI use:

JOINT_BACK_BKZ    = 0,
JOINT_BACK_BKY    = 1,
JOINT_BACK_BKX    = 2,
JOINT_NECK_AY     = 3,
JOINT_L_LEG_HPZ   = 4,
JOINT_L_LEG_HPX   = 5,
JOINT_L_LEG_HPY   = 6,
JOINT_L_LEG_KNY   = 7,
JOINT_L_LEG_AKY   = 8,
JOINT_L_LEG_AKX   = 9,
JOINT_R_LEG_HPZ   = 10,
JOINT_R_LEG_HPX   = 11,
JOINT_R_LEG_HPY   = 12,
JOINT_R_LEG_KNY   = 13,
JOINT_R_LEG_AKY   = 14,
JOINT_R_LEG_AKX   = 15,
JOINT_L_ARM_USY   = 16,
JOINT_L_ARM_SHX   = 17,
JOINT_L_ARM_ELY   = 18,
JOINT_L_ARM_ELX   = 19,
JOINT_L_ARM_UWY   = 20,
JOINT_L_ARM_MWX   = 21,
JOINT_R_ARM_USY   = 22,
JOINT_R_ARM_SHX   = 23,
JOINT_R_ARM_ELY   = 24,
JOINT_R_ARM_ELX   = 25,
JOINT_R_ARM_UWY   = 26,
JOINT_R_ARM_MWX   = 27,

... from AtlasRobotInterface_2.0.2/include/AtlasControlTypes.h

osrf-migration commented 11 years ago

Original comment by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

We're working with BDI on this issue, intending to make DRCSim match the released robot hardware and API as much as possible. BDI is understandably busy delivering robots right now, so there will likely be a bit of a delay.

osrf-migration commented 11 years ago

Original comment by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

Our first attempt to provide a matching API between hardware (AtlasRobotInterface, or ARI) and simulation will be to use a ROS<->ARI bridge process. It will expose a ROS message API that matches simulation and use libARI to talk with the robot.

A minimal version of this bridge is in the tutorials/atlas_interface_bridge package on the ari_bridge branch. To try it out, read the README.

Feedback welcome, whether on the overall approach or the specific implementation of the bridge.

Note that, here at OSRF, we don't have physical access to an Atlas, so we'll need teams' help in testing this sort of code.

osrf-migration commented 11 years ago

Original comment by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

Method 2:

Instead of using a separate ROS node as a bridge, which may introduce latency, and requires the use of ROS, link against a shim library that implements the same API as AtlasRobotInterface, but talks to simulation on the back end.

Kevin Knoedler kindly contributed his implementation of such a shim library, with permission for us to redistribute it with drcsim. His code, slightly modified, is packaged in the tutorials/atlas_interface package on the ari_bridge branch. To try it out, read the README.

Feedback welcome.

osrf-migration commented 11 years ago

Original comment by Brian Gerkey (Bitbucket: Brian Gerkey, GitHub: gerkey).

pull request #364 adds a couple of different methods for switching between simulation and hardware. More work needs to be done; please file separate tickets for things that are broken or missing.

osrf-migration commented 11 years ago

Original comment by David Conner (Bitbucket: dcconner).

I think we will pursue Method 2 using Kevin's code.

Is there a plan for managing code evolution and tracking feature requests for this interface. I suspect this will be more of a Track B/C team priority than an OSRF priority. It would be good to avoid duplicate efforts and share the work load of keeping this up to date if possible.